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

This article is about how to understand the Java design pattern responsibility chain pattern, the editor feels very practical, so share it with you to learn, I hope you can get something after reading this article, say no more, follow the editor to have a look.

I. definition of chain of responsibility model

   creates multiple objects, makes them form a chain, and passes the request along the chain until one of the objects on the chain decides to process the request.

Characteristics

1) the objects receiving the request are connected into a chain, and there is a hierarchical relationship between the objects.

2) these objects can process the request or pass the request until an object processes the request.

UML

The roles involved in the chain of responsibility model are as follows:

  -Abstract Handler role: defines the interface or abstract class that handles the request, provides methods for handling the request, and sets the next handler.

  -concrete handler role: implement or inherit the role of abstraction, and the specific logic is based on the actual architecture, which will be mentioned later.

II. Actual combat

Let's take a look at the abstract handler role code:

Public abstract class Handler {

Private Handler nextHandler

Private int level

Public Handler (int level) {

This.level = level

}

/ / handle request delivery. Pay attention to final. Subclasses cannot be rewritten.

Public final void handleMessage (Demand demand) {if (level = = demand.demandLevel ()) {

This.report (demand)

} else {if (this.nextHandler! = null) {

System.out.println ("the matter is too serious, need to report to a higher level")

This.nextHandler.handleMessage (demand)

} else {

System.out.println ("I am boss, no boss")

}

}

}

Public void setNextHandler (Handler handler) {

This.nextHandler = handler

}

/ / Abstract method, subclass implementation

Public abstract void report (Demand demand)

}

The abstract handler role defines abstract methods for handling requests, as well as object methods passed at the next level, focusing on how handleMessage handles request delivery. The following will explain why it is written this way and move on.

The following is the concrete handler role, which inherits the abstract handler role. In our scenario, there are two concrete handlers, the technical manager and boss.

/ / Technical Manager

Public class TechnicalManager extends Handler {

Public TechnicalManager () {

Super (1)

}

@ Override

Public void report (Demand demand) {

System.out.println ("requirements:" + demand.detail ())

System.out.println (getClass (). GetSimpleName () + "I support you, little ape, but I won't do it")

}

}

/ / boss

Public class Boss extends Handler {

Public Boss () {

Super (2)

}

@ Override

Public void report (Demand demand) {

System.out.println ("requirements:" + demand.detail ())

System.out.println (getClass (). GetSimpleName () + ": have a fight and decide if you win")

}

}

You can see that the code of the concrete handler is very concise, rewriting the report method to implement their respective business logic, all thanks to the handleMessage method in the parent class.

With both roles defined, let's see how the client implements:

Public class Client {public static void main (String [] args) {Demand demandA = new DemandA (); / / low request level Demand demandB = new DemandB (); / / High request level Boss boss = new Boss (); TechnicalManager technicalManager = new TechnicalManager (); technicalManager.setNextHandler (boss); / / set the next level technicalManager.handleMessage (demandA); System.out.println ("= =") TechnicalManager.handleMessage (demandB);}}

You can see that the focus in the client is to set up the handler at the next level, so that multiple handler objects form a chain. Run the client and the result is as follows:

Requirements: add a picture showing a little bit

TechnicalManager: I support you, little ape. I don't want to do this.

= =

Requirements: add a picture showing a little bit

TechnicalManager: the matter is too serious and needs to be reported to a higher level.

Boss: you can have a fight. Make the decision if you win.

As can be seen from the results, the low-level request technical manager handles it himself, and the high-level request is passed to the next level of Boss, which forms a chain, which is the core of the responsibility chain. Note that the request does not change during the delivery of the request. The demand will not change from "a picture with a little bit of dew" to "a picture with a dew point", waiting for boss to invite him to the office for tea.

Third, expand the responsibility chain + template method.

Looking back at the above code, several methods are defined in the abstract class, one is the final-decorated handleMessage, one is the abstract method report, and the other is setNextHandler. These happen to be the three basic methods in the template method pattern, namely concrete methods (abstract class declaration and implementation, subclass does not implement), abstract method (abstract class declaration, subclass must implement), hook method (abstract class declaration and implementation, subclass extensible). The handleMessage method is decorated with final, and the subclass cannot be overridden, while handleMessage gives the delivery request work to the parent class Handler, and the subclass does not need to handle the passing work. Report is an abstract method, and the subclass must override the method, and the subclass handles the business logic of the request. SetNextHandler is a hook method, which we didn't implement here.

What are the benefits of this combination of template approach patterns? First of all, the handleMessage method is added to separate the transmission judgment of the request from the subclass, so that the subclass can concentrate on the business logic of the request in the report method, thus achieving the principle of single responsibility. In addition, the implementation of the subclass becomes simple, and there is no need for passing judgment, which is very conducive to rapid expansion.

Chain of responsibility model VS observer model

I have written about the observer mode before. If you don't understand it, you can take a look at it first. There is one thing in common between the responsibility chain model and the observer model, that is, the transfer responsibility chain model is a level-by-level transmission, forming a chain, and there is a transmission relationship between the chain nodes (processors). On the other hand, the transmission of the observer mode from the observed to the observers is not the transmission between specific observers, and there is no connection between observers. Take the experience of Apes, for example, in the chain of responsibility model, there is a hierarchical relationship between the request from the technical manager to the boss, while for the observer mode is sent from the observed ape, both the technical manager and the boss as the observer will receive notification from the ape, which is diffuse, and there is no hierarchical relationship between the technical manager and the boss. This is the difference between the responsibility chain model and the observer model, and it is also the core of the responsibility chain model.

Fourth, the advantages and disadvantages of the responsibility chain model.

1) reduce the coupling: the client does not need to know which processor handles the request, and the processor does not need to know the transmission relationship between the processors, which is flexibly organized and allocated by the system.

2) good extensibility: the implementation of adding processors is simple, and only needs to rewrite the method of handling the request business logic.

Shortcoming

1) the request will be sent from the head of the chain until the processor responds, which will affect the performance of the system when the chain of responsibility is long.

2) request recursion, debugging and debugging is more troublesome.

The responsibility chain model can be used in many places in the actual project, such as the membership rating system, in which a chain is formed between the member levels, and the user initiates a request, and the system only needs to distribute the request to the entrance of the responsibility chain model. until it is passed to the level that matches the user member, so that the business logic of each member level will become very clear. This article has been tossing around for a long time, mainly to explain the core of the chain of responsibility clearly, so that everyone can easily understand, but also let me rethink the core of the chain of responsibility model. The next article is "I haven't decided yet". Your likes and concerns are my motivation. Goodbye!

The above is how to understand the Java design pattern responsibility chain pattern, the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please 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.