Chain of Responsibility (responsibility chain) of design patterns

Chain of responsibility definition
Chain of Responsibility (CoR) is a series of classes (classes) that attempt to process a request for requests, which are loosely coupled between these classes, and the only common denominator is to pass the request between them. That is, a request, a class first processing, if not processed, is passed to Class B processing, if not processed, passed to the Class C processing, just like a chain (chain) passed down.

How do I use it?
Although this section is how to use Cor, it is also a demonstration of what is Cor.

There is a handler interface:

 Public Interface handler{  publicvoid  handlerequest ();}

This is a case where request is handled, if there are multiple requests, such as requesting help, requesting printing, or requesting formatting.

The first solution to think of is to add multiple requests to the interface:

 Public Interface　　handler{  publicvoid  handlehelp ();　　 publicvoid  handleprint ();  publicvoid  Handleformat ();}

Specifically, a section of implementation interface handler code:

 Public classConcretehandlerImplementshandler{PrivateHandler successor;  PublicConcretehandler (Handler successor) { This. successor=successor; } Public voidHandlehelp () {//the code that specifically handles the request for Help...}  Public voidHandleprint () {//if it is print, go to processing printSuccessor.handleprint (); } Public voidHandleformat () {//if format is transferred to process formatSuccessor.handleformat (); }}

A total of three such specific implementation classes, above is the processing of help, as well as processing print processing format This is probably our most commonly used programming ideas.

Although the idea is simple and straightforward, there is an extension problem, and if we need to add a request type again, we need to modify the interface and each of its implementations.

Scenario two: Each request becomes an interface, so we have the following code:

 Public Interfacehelphandler{ Public voidhandlehelp ();} Public Interfaceprinthandler{ Public voidhandleprint ();} Public Interfaceformathandler{ Public voidHandleformat ();} Public classConcretehandlerImplementshelphandler,printhandler,formathandlet{PrivateHelphandler Helpsuccessor; PrivatePrinthandler Printsuccessor; PrivateFormathandler Formatsuccessor;  PublicConcretehandler (Helphandler helpsuccessor,printhandler printsuccessor,formathandler formatSuccessor) {  This. helpsuccessor=Helpsuccessor;  This. printsuccessor=Printsuccessor;  This. formatsuccessor=Formatsuccessor; } Public voidhandlehelp () {...}  Public voidHandleprint () { This. printsuccessor=Printsuccessor;}  Public voidHandleformat () { This. formatsuccessor=formatsuccessor;}}

This method in the case of adding a new request, just save the interface modification, interface implementation Concretehandler also need to be modified. And the code is obviously not simple and beautiful.

Solution 3: Use only one parameterized method in the handler interface:

 Public Interface handler{  publicvoid  handlerequest (String request);

Then the handler implementation code is as follows:

 Public classConcretehandlerImplementshandler{PrivateHandler successor;  PublicConcretehandler (Handler successor) { This. successor=successor; } Public voidHandleRequest (String request) {if(Request.equals ("Help")) {//here is the specific code to process Help}Else 　　　　　　 //Pass to the nextSuccessor.handle (Request); }}}

First, suppose the request is of type string, and if not what? Of course we can create a special class request

The Final Solution: the code for Interface handler is as follows:

 Public Interface handler{  publicvoid  handlerequest (Request request);

Definition of the Request class:

 Public class　　request{  private  String type;　　  public Request (String type) {this. type=type;}　　  public String getType () {return  type;}  publicvoid  execute () {  //request true Specific behavior code }} 

Then the handler implementation code is as follows:

 Public classConcretehandlerImplementshandler{PrivateHandler successor;  PublicConcretehandler (Handler successor) { This. successor=successor; } Public voidHandleRequest (Request request) {if(Requestinstanceofhelprequest) {//here is the specific code to process Help}Else if(Requestinstanceofprintrequst)　　　　{Request.execute (); }Else 　　　　　　 //Pass to the nextSuccessor.handle (Request); }}}

The solution is Cor, which has a class of corresponding duties on a chain, so called Chain of Responsibility.

Advantages of Cor:
Because there is no way to predict what type of request is from the outside world, each class can just give up if it encounters a request that it cannot handle. Undoubtedly, this reduces the coupling between classes.

The disadvantage is inefficient, because the completion of a request may be traversed to the last possible completion, of course, can also be optimized with the concept of the tree. In Java AWT1.0, the handling of the mouse button is to use Cor, and after java.1.1, use observer instead of COR

Poor scalability, because in the COR, there must be a unified interface handler. The limitations are here.

Transferred from: http://www.jdon.com Banqiao

Chain of Responsibility (responsibility chain) in design mode (RPM)