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

In this article, the editor introduces in detail the "Chain of Responsibility chain of responsibility model how to achieve", the content is detailed, the steps are clear, and the details are handled properly. I hope this article "how to achieve the Chain of Responsibility chain of responsibility mode" can help you solve your doubts.

Chain of Responsibility (responsibility chain mode)

Chain of Responsibility (responsibility chain model) belongs to the behavioral model. Behavioral patterns describe not only the patterns of objects or classes, but also the communication patterns between them, such as how the handling of operations should be passed, and so on.

Intention: to give multiple objects the opportunity to process the request, thus avoiding the coupling between the sender and receiver of the request. Concatenate these objects into a chain and pass the request along the chain until an object processes it.

Almost all design patterns have been encountered in practice before I learned about them, so design patterns are indeed true knowledge derived from practice. But on the other hand, if there is no practical understanding, just looking at the design pattern is boring and difficult to understand, so when we learn the design pattern, we should think about it in combination with practical problems.

As an example

If you do not understand the above intention introduction, it does not matter, the design pattern needs to be used in daily work, combined with examples can deepen your understanding, below I have prepared three examples to let you experience in what scenarios this design pattern will be used.

Middleware mechanism

Imagine that we want to implement middleware for a back-end framework (students who know Koa can understand it as the onion model of Koa). Any number of middleware can be inserted into the code, each of which can handle requests and responses.

Since each middleware only responds to the requests of its own interest, only the runtime knows whether the middleware will handle requests, so how should the middleware mechanism be designed to ensure its function and flexibility?

General help copywriting

If a large system, any module click will pop up help copy, but not every module has help copy, if a module does not help copy, then display its parent help copy, if no more, continue to bubble to the entire application, show application-level help copy. How should this system be designed?

Bubbling mechanism of JS events

In fact, JS event bubbling mechanism is a typical responsibility chain pattern, because any DOM element can listen, such as onClick, not only can respond to events themselves, but also use event.stopPropagation () to stop bubbling.

Intention interpretation

The bubbling mechanism of JS events is all too common for the front end, but if we look at it from a different perspective, we can rediscover the subtlety of its design from the perspective of click events:

Click events are superimposed on each layer of dom, because the handling and binding of dom to events is dynamic, the browser itself does not know where to deal with click events, but it is necessary to let each layer of dom have the "equal right to handle click events", so there is a bubbling mechanism and event prevention bubbling function.

General help copy is very similar to JS event bubbling, except that the click event is replaced with pop-up help copy, and the scenario mechanism is the same.

Speaking of which, we can re-understand the intention of the chain of responsibility model:

Intention: to give multiple objects the opportunity to process the request, thus avoiding the coupling between the sender and receiver of the request. Concatenate these objects into a chain and pass the request along the chain until an object processes it.

A request refers to a request generated by a trigger mechanism and is a general concept. "avoid coupling between the sender and receiver of the request" means that if only one object has the opportunity to process the request, then the receiver and the sender are coupled. Other receivers must pass through this receiver in order to continue to process, this mode is not flexible enough.

The second half of the sentence describes how to design a flexible pattern that connects objects into a chain and passes the request along the chain until an object processes it. Also understand that any object has the ability to block the continued delivery of the request.

In the example of middleware mechanism, the processing of Http request by the back-end Web framework is a typical case of using the responsibility chain pattern, because the request to be processed by the back-end framework is parallel, any request may be responded to, but the processing of the request is extended through the plug-in mechanism, and the processing of each request is a chain, and there is a logical relationship of processing, processing, and reprocessing.

Structure diagram

Handler is the processing of the request. You can see that this is a loop. As long as it is processed, it can be handed over to the next Handler for processing. It can be interrupted after interception, or it can penetrate the entire link.

ConcreteHandler is the implementation of concrete Handler, and they all need to inherit Handler to have the same HandleRequest method, so that each processing middleware has the processing power, so that the chain of these objects can pass the request.

Code example

There are many ways to implement the chain of responsibility, such as Koa's Onion Model implementation principle is worth writing another article, interested students can read the co source code. Only the implementation of the simplest scenario is introduced here.

There are also two simple implementation patterns of the chain of responsibility, one is that each object itself is maintained to the reference of the next object, and the other is that the successor is maintained by Handler.

The following example is written in typescript.

Public class Handler {

Private nextHandler: Handler

Public handle () {

If (nextHandler) {

NextHandler.handle ()

}

}

}

The default behavior of each Handler is to trigger the handle of the next chain, so if you do nothing, the chain is fully open, so we can deal with it on any link in the chain.

The way to deal with it is to rewrite the handle function, and when we rewrite it, we can maintain the call to nextHandler.handle () so that the chain continues to pass backward, or it doesn't have to be called, thus terminating the backward passing of the chain.

Malpractice

The chain of responsibility pattern does not guarantee that every middleware has the opportunity to process requests, because of the order of the middleware, the back middleware may be blocked by the previous middleware, so when there is a mistrust relationship between the middleware, the chain of responsibility pattern does not guarantee the reliability of middleware calls.

In addition, do not expand the scope of use of the design pattern, it is not necessary to use the chain of responsibility pattern for continuous calls to a bunch of objects, because the chain of responsibility is suitable for dealing with scenarios where the number of objects is uncertain and whether or not to handle requests is flexibly determined by each object. and determine the number of objects and whether to invoke the scenario, it is not necessary to use the responsibility chain pattern.

Read here, this article "how to achieve the Chain of Responsibility chain of responsibility model" article has been introduced, want to master the knowledge of this article also need to practice and use to understand, if you want to know more about the article, welcome to follow the industry information channel.

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.