Shulou(Shulou.com)06/01 Report--

The content of this article mainly focuses on what is the design idea of xunit. The content of the article is clear and clear. It is very suitable for beginners to learn and is worth reading. Interested friends can follow the editor to read together. I hope you can get something through this article!

Design ideas

The working mode of any system, module, and processing unit can be simplified to an IPO model, that is, a certain input is transformed into a certain output through the actions defined by the module:

Input-> process-- > output.

Because there is no essential difference between input and output in terms of the attributes of the data itself, xunit abstracts the input / output data as a Context interface.

Package com.xrosstools.xunit;public interface Context {}

Then the conversion behavior between input and output is defined as an interface, which is called a behavioral component.

The most basic Converter interface, its job is to convert input Context into output Context.

If the input and output are of the same concrete type (the concrete implementation class of Context), the Converter interface can be simplified to the Processor interface. That is, only the input Context is received, but no value is returned. Processor generally handles the internal properties of the input Context.

Due to the division of functions, it is necessary to combine multiple behavioral components into a larger structure, which is called structural components.

Connect different Converter or Processor in turn, let Context flow from the first processing unit to the last processing unit, in order to complete a series of actions, this most basic structure is the structural component Chain.

If you need to choose one of the two behavior components, you need to judge the Context. The behavior component that encapsulates judgment is another variant of Converter, Validator. Validator determines the Context and returns an output of type Boolean. With Validator, you can combine structural components like BiBranch.

Similarly, sometimes we need to choose between multiple behavior components based on Context, and the component that encapsulates the selection behavior is another variant of Converter, Locator. Locator identifies the identifiers of the Context and returns an output of type String. With Locator, it can be combined into a structural component like Branch.

Based on Validator and individual behavior components, we can also build While Loop and Do While loop structural components to complete the loop operation of pre-or post-condition judgment.

If you want to reuse an existing behavioral component, but the interface is different from what we need, you can adapt it through Adapter.

If you want to decorate a component, you can use the Decorator component. The behavior of Decorator is automatically consistent with that of the decorated component.

module

The components of xunit can be divided into behavioral components and structural components. Behavioral components are defined for the processing that Context can do; structural components are combined to combine multiple behavioral components into larger and more complex behavioral components. Unlike behavioral components, the behavior patterns of structural components need to be specified manually, and the default is Processor.

Behavior component processor

Context is processed, but no value is returned

Public interface Processor extends Unit {void process (Context ctx);}

Converter

Transform the incoming context into a new Context. You can also return the original Context

Public interface Converter extends Unit {Context convert (Context inputCtx);}

Validator

Judge Context by true or false

Public interface Validator extends Unit {boolean validate (Context ctx);} locator

To judge the classification of Context. Default values are supported

Public interface Locator extends Unit {String locate (Context ctx); void setDefaultKey (String key); String getDefaultKey ();} dispatcher

Copy, distribute, and merge Context

Public interface Dispatcher extends Unit {void setCompletionMode (CompletionMode mode); CompletionMode getCompletionMode (); void setTimeout (long timeout); long getTimeout (); void setTimeUnit (TimeUnit timeUnit); TimeUnit getTimeUnit (); Map dispatch (Context inputCtx, Map taskInfoMap); / / For CompletionMode.none, the results will be empty list Context merge (Context inputCtx, List results); Context onInvokeError (Map dispatchedContexts, Exception exception); Context onTaskError (Context taskCtx, Exception exception);}

Each branch can specify a Task Type attribute, and there are currently three:

Normal: an ordinary task, which must be completed according to CompletionMode

Mandatory: tasks that must be done, work with critical CompletionMode

Standalone: tasks performed separately. There is no need to worry about whether it is completed or not, and do not participate in the merge operation of dispatcher

CompletionMode is the way concurrent tasks are executed, and there are currently four ways:

Public enum CompletionMode {all, any, critical, none;}

All: all execution of normal has been completed

Any: execution of any normal has been completed

Critical: all mandatory execution is complete

None: invokes all branches and does the following without waiting for a return

Structural component chain

Scheduling processing of the internal unit sequentially. Context will be processed sequentially.

If-else

The internal unit is called through the Validator decision. Also known as BiBranch

Branch

Judge the unit inside the dispatch by Locator

Parallel branch

Schedule some or all of unit concurrently through Dispatcher

While loop

While structure judged by Validator

Do while loop

Do while structure judged by Validator

Decorator

Processing before and after operation

Public interface Decorator extends Adapter {/ * Extends this method to provide decoration before decorated unit executed * @ param ctx * / void before (Context ctx); / * * Extends this method to provide decoration after decorated unit executed * @ param ctx * / void after (Context ctx);}

Adapter

Convert the behavior of one unit into another

Public interface Adapter extends Unit {void setUnit (Unit unit);}

Unit reference

If the flowchart is complex, some parts of the diagram can be extracted into a separate diagram and then referenced on the original diagram. By default, xunit will identify other xunit files in the same directory as the current xunit file as an optional module.

For example:

If a xunit file has been selected for this unit, the tag is displayed in front of the selected module.

If the module you want to select is not in the same directory as the current file, you can specify a specific path through the Reference to module dialog box.

When a module is selected, its internal optional cells are listed. Those that have been selected will be marked.

If no external module is selected, all units of the current module that can be referenced by the currently selected unit are displayed by default

Automatic attribute recognition

As long as any component defines a static String constant at the beginning of PROP_KEY, after opening through the editor, the contents of the defined constant can be recognized and displayed by the editor as configurable properties of the component. These properties are set through the UnitPropertiesAware interface when the component is created.

For example, the attribute definition of DefaultUnitImpl:

* public static final String constant with name start with PROP_KEY will be displayed * in "Set property" context menu * / public static final String PROP_KEY_SHOW_MESSAGE = "showMessage"; public static final String PROP_KEY_SHOW_FIELDS = "showFields"; public static final String PROP_KEY_SHOW_APP_PROP = "showApplicationProperties"; / / The method take higher prioritypublic static final String PROP_KEY_EVALUATE_METHOD = "evaluateMethod"; public static final String PROP_KEY_EVALUATE_FIELD = "evaluateField"; public static final String PROP_KEY_VALIDATE_DEFAULT = "validateDefault"

These attributes can be displayed in the editor:

The advantage of this is that the components can be self-interpreted and it is convenient for other users to integrate. Of course, there is no definition, and users can create their own at any time.

Treatment of structural inconsistency

Structural components generally require that the behavior components contained within them are consistent with the behavior patterns defined by the structural components themselves. In the case of different situations, consistency can be maintained through Adapter. In order to reuse existing components efficiently and avoid frequent configuration of a large number of simple and repetitive Adapter, structural components have built-in a simple adaptation mechanism. Take Chain as an example:

If the behavior mode of Chain is Converter and the Chain contains Processor, the input Context of Processor is passed to the next unit as the result of Convert.

If the behavior mode of the Chain is Processor and the Chain contains Converter, the convert method of the Converter is called, but the converted output Context is discarded. The initial input Context is passed to the next unit.

Thank you for your reading. I believe you have a certain understanding of "what is the idea of xunit design?" go ahead and practice it. if you want to know more about it, you can pay attention to the website! The editor will continue to bring you better articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.