Behavioral patterns of design patterns (i)

Design patterns are divided into three main types: creation, structure and behavior. This article describes the observer patterns, template method patterns, command patterns, state patterns, and responsibility chain patterns in behavioral patterns.

Viewer mode: defines a one-to-many dependency between objects, and when an object's state changes, all objects that depend on it are notified and automatically updated.

Pros: The Observer pattern relieves the coupling between the subject and the specific observer, allowing both sides of the coupling to rely on abstraction rather than reliance on specifics. So that their changes will not affect the other side of the change.

Cons: The dependency is not completely lifted, and the abstract notifier still relies on the abstract observer.

Application: (1) When the change of an object needs to be changed to another object, and it does not know how many objects are to be changed. (2) An abstract type has two aspects, when one aspect depends on another, then the observer pattern can be encapsulated in a separate object so that they are independently changed and reused.

Template Method Mode: defining an algorithmic skeleton for an operation, and delaying some steps into subclasses, the template method allows subclasses to redefine some specific steps of the algorithm without altering the structure of an algorithm.

Advantages: (1) The template method pattern removes duplicate code from subclasses by moving the invariant behavior to the superclass. (2) Subclasses implement some of the details of the algorithm, which helps to extend the algorithm. (3) through a parent class call the subclass implementation of the operation, through the subclass extension to add new behavior, in line with the "open-closed principle."

Cons: Each different implementation needs to define a subclass, which causes the number of classes to increase and the design to be more abstract.

Applications: (1) in some classes of algorithms, the same method is used, resulting in code duplication. (2) Control subclass extension, subclasses must obey algorithm rules.

Command mode: encapsulates a request as an object so that you can parameterize the customer with different requests, queue or log requests, and support revocable operations.

Advantages: (1) The coupling between the requester and the implementation is relieved, and the coupling degree of the system is reduced. (2) Queue or record request log, support revocation operation. (3) It is easy to design a combination command. (4) New commands can be easily added to the system.

Disadvantage: Because of the need to design a specific command class for each command, using the command pattern may cause the system to have too many specific command classes.

Application: (1) when the behavior needs to be "record, undo/redo" and other processing. (2) The system needs to decouple the requestor and receiver so that the caller and receiver do not interact directly. (3 The system needs to specify requests, queue requests, and execute requests at different times.) (4) The system needs to combine a set of operations, that is, macro commands are supported.

State mode: allows an object to change its behavior when its state changes, so that the object seems to modify its class.

Advantages: (1) The state mode will localize the behavior associated with a particular state and separate the behavior of the different states. (2) All state-related code is present in a conceretestate, so it is easy to add new states and transformations by defining new subclasses. (3) The state mode reduces the dependence of each other by transferring the logic of various state transitions to the sub-classes of States.

Disadvantage: lead to more concretestate subclasses.

Application: (1) When an object's behavior depends on its state, and it must change its behavior based on state at run time, consider using state mode. (2) An operation contains a large branching structure, and these branches are determined by the state of the object.

Responsibility Chain Mode: enables multiple objects to have the opportunity to process requests, thus avoiding the coupling between the sender and receiver of the request. Link the objects together and pass the request along the chain until an object handles it.

Advantages: (1) The responsibility chain mode makes an object need not know which object to handle its request, the object only needs to know that the request is processed, the receiver and sender have no explicit information, and the object in the chain does not need to know the structure of the chain, the client is responsible for the creation of the chain, reducing the system coupling degree. (2) The request processing object only needs to maintain a reference to the subsequent successor, and does not need to maintain its reference to all the candidate handlers, which simplifies the object's mutual connection. (3) When assigning responsibilities to an object, the chain of responsibility gives us more flexibility to increase or change the responsibility for handling a request by dynamically adding or modifying the chain at run time. (4) In the system to add a new specific request processor without modifying the original system code, only need to re-build the chain on the client, from this point of view is in line with the "open and closed principle."

Cons: (1) because a request does not have a clear recipient, there is no guarantee that it will be processed, and the request may not be processed until the end of the chain, and a request may not be processed because the responsibility chain is not properly configured. (2) for a longer chain of responsibility, the processing of the request may involve multiple processing objects, the system performance will be affected, and the code debugging is not very convenient. (3) If the chain is improperly built, it can cause cyclic calls, which will cause the system to fall into a dead loop.

Application: (1) There are multiple objects that can handle the same request, which object handles the request to be run and then determines that the client simply commits the request to the chain without needing to care who the requested processing object is and how it is handled. (2) In cases where the recipient is not explicitly specified, a request is submitted to one of several objects. (3) A set of object processing requests can be dynamically specified, and the client can dynamically create a chain of responsibilities to process requests and change the order of the handlers in the chain.

Behavioral patterns of design patterns (i)