Chain of Responsibility Definition CHAIN of Responsibility (COR) is a series of classes attempts to process a request request, which is a loose coupling, and the only thing is to pass the request between them. That is to say, come A request, A-class processed, if not processed, pass to class B processing, if there is no processing, pass to C to Class C processing, which is transmitted like a chain (chain).
How to use? Although this section uses COR, but also demonstrates what is COR.
There is a Handler interface:
Public interface handler {public void handlerequest ();
This is an example of processing Request, if there are multiple requests, such as requesting help request printing or request formatting: The first thought solution is: Add multiple requests in the interface: public interface handler {public void handleHelp (); Public void handleprint (); public void handlex ();
}
Specifically, an implementation interface Handler code: public class concretehandler imports handler {private handler success
Public Concretehandler (Handler Success "{this.successor = SUCCESSOR;
Public void handlehelp () {// Confident processing request Help code ...}
Public void handleprint () {// If it is a print snoring processes print success,} public void handleFormat ()} If it is format rotation process ();
} There are three such specific implementations, which are processed to handle HELP, and process Print processing Format is probably our most common programming idea.
Although the idea is simple, there is an extension problem. If we need to add a request request type, you need to modify the interface and each of its implementations.
Second Solution: Both each request becomes an interface, so we have the following code:
Public interface helphandler {public void handlehelp ();
Public interface printhhandler {public void handleprint ();
Public interface formathandler {public void handlex ();
Public Class Concretehandler Implements Helphandler, PrintHandler, FormatHandlet {Private Helphandler Helpsuccessor; Private Printhandler PrintSuccessor; Private Formathandler FormatSuccessor;
public ConcreteHandler (HelpHandler helpSuccessor, PrintHandler printSuccessor, FormatHandler formatSuccessor) {this.helpSuccessor = helpSuccessor; this.printSuccessor = printSuccessor; this.formatSuccessor = formatSuccessor;} public void handleHelp () {.......}
Public void handleprint () {this.printsuccessor = printsuccessor;
Public void handleformat () {this.formatSuccessor = formatsuccessor;
}
This approach increases the new request request, but saves the modification of the interface, and the interface implementation ConcreteHandler needs to be modified. And the code is obviously not simple and beautiful.
Solution 3: Only one parameterization method is used in the Handler interface: public interface handler {public void handlerequest (String request);} The Handler implementation code is as follows: Public class contradehandler implements handler {private handler success
Public Concretehandler (Handler Success "{this.successor = SUCCESSOR;
Public void handlerequest (String Request) {if (Request.Equals ("Help")) {// Here is the specific code of HELP} else // is passed to the next sucpsor.handle (request);
}
}
Here first, it is assumed to be a string type, if not what is wrong? Of course we can create a specialized request
Last Solution: Interface Handler code is as follows: public interface Handler {public void handleRequest (Request request);} defined Request class: public class Request {private String type; public Request (String type) {this.type = type;}
Public string gettype () {return type;}
Public void execute () {// request real specific behavior code}} The Handler implementation code is as follows: Public class concretehandler implements handler {private handler success
Public Concretehandler (Handler Success "{this.successor = SUCCESSOR;
public void handleRequest (Request request) {if (request instanceof HelpRequest) {// This is the specific code} else if (request instanceof PrintRequst) {request.execute () Help the process;} else // passed to the next successor.handle (REQUEST);}}
}
This solution is COR, in a chain, there is a class of corresponding responsibilities, so it is called Chain of Responsibility.
Advantages of COR: Because it is not possible to predict which type of request is belonging to it, if each class can be given to the request, it is possible.
The disadvantage is that the efficiency is low because the completion of a request may be traversed to finally complete, and of course it can also be optimized with the concept of trees. In Java AWT1.0, the processing of the mouse button is to use COR. After java.1.1, use Observer instead of COR.
Due to the spread, because in COR, there must be a unified interface handler. Limitations are here.
Difference to the Command mode:
Command mode requires the call relationship between the client and the server side in advance, such as 1 represents START 2 represents Move, etc., which are encapsulated in the Request, reach the server. Decompose.
Cor mode does not need this prior agreement, the server side can use the COR mode to speculate on the client request, one of the speculation tests.
