Design pattern Summary-behavioral patterns

Behavioral patterns

Behavioral patterns involve the allocation of duties between algorithms and objects. Behavior patterns describe not only the patterns of objects and classes, but also the communication patterns between them. These patterns depict complex control flows that are difficult to track at run time. They divert your attention from the flow of control to the contact between objects. Compared with the creation pattern and the structural pattern described in the previous two articles, they emphasize the relationship between the static class entities, while the behavioral pattern focuses on the communication relationship between the class entities.

There are several common behavioral patterns, namely observer mode, template method mode, command mode, State mode, responsibility chain mode, interpreter mode, mediator mode, visitor mode, policy mode, Memo mode, and iterator mode.

Observer pattern

The Observer pattern defines a one-to-many dependency that allows multiple observer objects to listen to a Subject object at the same time. When this subject object changes, all the observer objects are notified so that they can automatically update themselves.

Conditions of Use:

When the change of an object needs to change other objects at the same time, and do not know how many objects need to be changed, an abstract pattern has two aspects, one on the other hand, the two are encapsulated in separate objects to change and reuse independently; When an object must notify other objects, And it cannot assume that other objects are who, in other words, do not want these objects to be tightly coupled.

In general the work of the observer pattern is actually decoupling. Let both sides of the coupling rely on abstraction, rather than relying on specifics. So that their changes will not affect the other side of the change.

The class diagram is as follows:

Template method Mode

The template method pattern defines the skeleton of an algorithm in an operation, and some steps are deferred to subclasses, and the template method allows subclasses to redefine some specific steps of the algorithm without altering the structure of an algorithm.

Conditions of Use:

Some of the process of column steps need to be executed, the process is the same at a high level, but some steps may be implemented differently.

The template method pattern is to provide a good code reuse platform by moving the invariant behavior to the superclass and removing the duplicated code in the subclass to embody its advantage.

The class diagram is as follows:

Command mode

The command pattern encapsulates a request as an object, allowing you to parameterize the customer with different requests, queue requests or log requests, and support actions that can be undone.

Conditions of Use:

The original code can be refactored into a command mode only if it really needs functions such as undo/redo operations.

The class diagram is as follows:

State mode

State mode when an object's internal state changes to allow its behavior to change, the object looks like it has changed its class.

Conditions of Use:

When the behavior of an object depends on its state, and it must change other behaviors according to state at run time, when the conditional expression that controls an object state transition is too complex, the judgment logic of the state is transferred to a series of classes representing different states, which simplifies the complex judgment logic.

State patterns localize the behavior associated with a particular state and separate the behavior of different states to eliminate large conditional branching statements.

The class diagram is as follows:

Responsibility chain Model

The responsibility chain pattern allows multiple objects to have the opportunity to process requests, thus avoiding the coupling between the sender and receiver of the request. Practice this object as a chain and pass the request along this chain until an object has processed it.

Conditions of Use:

There are multiple objects that can handle a request, which object handles that request automatically when the runtime is determined, and to commit a request to one of multiple objects without explicitly specifying the recipient.

Both the receiver and the sender have no object-specific information, and the chain object itself does not know the structure of the chain, and the chain only needs to maintain a reference to the subsequent successor, without requiring all of its candidate recipients.

The class diagram is as follows:

Interpreter mode

The interpreter pattern is given a language, defines a representation of its grammar, and defines an interpreter that uses that representation to interpret sentences in the language.

Conditions of Use:

When there is a language that needs to be interpreted and executed, and you can represent a sentence in that language as an abstract syntax tree, it might be worthwhile to describe each instance of the problem as a sentence in a simple language if the frequency of a particular type of problem occurs sufficiently high. This allows you to build an interpreter that solves the problem by interpreting these sentences.

Interpreter mode is to use "mini-language" to show the program to solve the problem, has been written in mini-language "mini-program" to express specific problems.

The class diagram is as follows:

Broker mode

The mediator pattern is the use of a mediation object to encapsulate a series of object interactions. The mediator makes the objects do not need explicit mutual references, so that they are loosely coupled, and can independently change the interaction between them.

Conditions of Use:

An occasion to apply to a set of objects to communicate in a well-defined but complex way, and to customize a behavior that is distributed across multiple classes without having to generate too many subclasses.

The mediator pattern encapsulates the collective behavior of a single Mediator object to avoid this problem, the mediator is responsible for controlling and coordinating the interaction between a set of objects, and the mediator acts as a mediator so that the objects in the group no longer display references to each other, and these objects only know the mediator, thereby reducing the number of connections.

The class diagram is as follows:

Visitor mode

The visitor pattern represents an operation that acts on elements in an object's structure. It allows you to define new actions that act on these elements without changing the class of each element.

Conditions of Use:

There are more stable data structures or systems with relatively stable data structures, and there are easy-to-change algorithms that often require the definition of new operations on data structures.

It is difficult to add a specific data structure to the visitor pattern, but it is easier to add a build that relies on complex object structures, just to add a new visitor to define a new operation on an object structure.

The class diagram is as follows:

Policy mode

The policy pattern defines some algorithms, encapsulates them one by one, and allows them to be replaced with each other, while making the algorithm independent of the customers who use it.

Conditions of Use:

The possibility of this change can be handled with a policy pattern when different business rules are applied at different times.

The strategy pattern defines a series of algorithms, conceptually, all of these algorithms are doing the same thing, just implementing different, it can call all the algorithms in the same way, reducing the coupling between the various algorithm classes and using the algorithm class. Further, the strategy pattern is used to encapsulate the algorithm, but in practice we find that it can be used to encapsulate almost any type of rule.

The class diagram is as follows:

Memo Mode

The memo pattern captures the internal state of an object without breaking the encapsulation, and saves the state outside of the object. The object can then be restored to its previously saved state.

Conditions of Use:

For classes that are more complex, but need to maintain or record property history, or if you need to save a property that is only part of a number of properties, you can revert to the previous state based on the saved information, and if you use command mode in a system, you need to implement the Undo function of the command. Then the command mode can use Memo mode to store the state of the revocable operation, and the memo can be used to mask the complex object's internal information to other objects; When the role state changes, it is possible that the state is not valid, so you can use the temporarily stored memo to restore the state

The class diagram is as follows:

Iterator mode

The iterator pattern provides a way to sequentially access individual elements in an aggregated object without exposing the object's internal representation.

Conditions of Use:

You need access to a clustered object, regardless of what these objects need to traverse, when there are multiple ways to traverse the aggregation, and provide a unified interface for traversing different aggregation structures.

The iterator pattern is the separation of the traversal behavior of the collection object and the abstraction of an iterator class to be responsible for not exposing the internal structure of the collection, but also allowing the external code to transparently access the data inside the collection.

The class diagram is as follows: