Behavior mode VB. NET

Behavior mode

 

Observer (dependency inversion)

Defines a one-to-many dependency between objects. When the status of an object changes, all objects dependent on it are notified and automatically updated.

 

Objects, especially specific objects, do not affect each other only when they are changed. For the observer mode, the object and the observer are not closely coupled. They can belong to different abstract layers in a system. What the object knows is that it has a series of observers, each Observer implements a simple interface of the observer. The goal is not to know which specific class the observer belongs. In this way, the tight coupling relationship between objects can be removed.

 

Template (Rishi replacement)

Defines the algorithm skeleton of an operation and delays some steps to the subclass. The template method allows the subclass to redefine some specific steps of the Algorithm without changing the structure of an algorithm.

 

Code duplication is the most common and worst "Bad taste" in programming. If we see the same program structure in more than one place, we can be sure to combine them into one, the program will become better. Of course, there are obvious duplicates of identical code, and subtle duplicates will appear in seemingly different structures or processing steps that are essentially the same, so we must be careful with them.

 

One of the major advantages of inheritance is that you can get something from the base class for free. When you inherit a class, the derived class will immediately get all the functions of the base class, you can also add any new features on the basis of it.

 

The template method mode is composed of an abstract class, which defines the template methods that need to be overwritten and may have different implementations. Each specific class derived from this abstract class will implement a new method for this template. In this way, repeated codes are extracted into abstract classes, which achieves code reuse.

 

Command (single responsibility)

Encapsulate a request as an object to parameterize the customer with different requests. You can queue requests or record request logs, and support auditable operations.

 

Separating request senders from specific implementers means decoupling the objects that call the operation from those that know how to implement the operation. The command mode allows you to specify, sort, and execute requests at different times. You can store the status before performing the operation to support cancel/Redo operations. You can also record the logs of the entire operation so that you can find the cause or resume redo when a system problem occurs. This also means that the command mode supports transactions. Either all commands are successfully executed, or they are restored to a state where nothing is executed. In short, if there is a similar request, using the command mode to separate the requestor from the real-time is the best choice.

 

Status

Allows an object to change its behavior when its internal state changes, so that the object seems to have modified its class.

 

In programming, a large number of applications of the condition branch are often encountered. If the condition branch statement does not involve important business logic or does not change with time, it will not have any scalability, that is to say, it will almost never change. In this case, the condition branch should be used. However, there are many premises, and these premises are often not true. In fact, there are few requirements that will not change, and there are few software that does not need to be extended, it is very important to break down such branch statements and encapsulate them into multiple sub-classes and use polymorphism to improve their maintainability and scalability.

 

The State mode provides a better way to organize Code related to a specific State. The logic for determining the State transfer is not in the IF or switch of a single block, but distributed among the State subclasses, all status-related code exists in a status subclass, so it is easy to add new States and transformations by defining a new subclass.

 

Responsibility chain

So that multiple objects have the opportunity to process the request, so as to avoid coupling between the request sender and the receiver. Connect these objects into a chain and pass the request along the chain until an object processes it.

 

Similarly, the request sender is separated from the specific implementer. We often encounter this situation: there are multiple objects that can process a request, but the object that processes the request is unknown in advance and must be automatically determined at runtime. At this time, the best way is to separate the request sender from the specific processing, so that the customer can submit a request without specifying the receiver explicitly, then, all the objects that can process this request are connected into a chain, and the request is passed along this chain, until an object processes it.