Beauty of design patterns: Chain of Responsibility)

The intention gives multiple objects the opportunity to process the request, thus avoiding the coupling relationship between the request sender and the receiver. Connect these objects into a chain and pass the request along the chain until an object processes its location. Avoid coupling the sender of a request to its own er by giving more than one object a chance to handle the request. chain the processing objects and pass the request along the chain until an object handles it. A typical object structure may be shown in: the participant Handler defines an interface for processing requests. Implement the successor chain ConcreteHandler to process the requests it is responsible. Can access its successor. If the request can be processed, it will be processed; otherwise, the request will be forwarded to its successor. The Client submits a request to the specific handler object on the chain. Applicability: the Chain of Responsibility mode can be used in the following cases: Multiple objects can process a request, and the object automatically determines when processing the request. You want to submit a request to one of multiple objects without specifying the receiver explicitly. The object set that can process a request should be dynamically specified. The effect reduces coupling. The object does not need to know which object is processing its request, but only needs to know that the object is being processed. This enhances the flexibility of assigning roles to objects. You can dynamically add or modify the chain during running. The related mode Chain of Resposibility is often used with Composite. The parent component of a component can be used as its successor. Implementation Method (1): implement the successor chain. Copy code 1 namespace ChainOfResponsibilityPattern. implementation1 2 {3 public enum RequestCategory 4 {5 Category1, 6 Category2, 7} 8 9 public abstract class Request 10 {11 public abstract RequestCategory {get ;} 12 public bool IsHandled {get; set;} 13} 14 15 public class ConcreteRequest1: Request 16 {17 public override RequestCategory Category 18 {19 get {return RequestCategory. ca Tegory1;} 20} 21} 22 23 public class ConcreteRequest2: Request 24 {25 public override RequestCategory Category 26 {27 get {return RequestCategory. category2;} 28} 29} 30 31 public abstract class Handler 32 {33 private Handler _ successor; 34 35 public Handler () 36 {37} 38 39 public Handler (Handler successor) 40 {41 _ successor = successor; 42} 43 44 public void Handle (Request request) 45 {46 OnHandle (request); 47 48 if (! Request. IsHandled) 49 {50 if (_ successor! = Null) 51 {52 // pass request to successor 53 _ successor. handle (request); 54} 55} 56} 57 58 protected abstract void OnHandle (Request request); 59} 60 61 public class ConcreteHandler1: Handler 62 {63 public ConcreteHandler1 () 64 {65} 66 67 public ConcreteHandler1 (Handler successor) 68: base (successor) 69 {70} 71 72 protected override void OnHandle (Request request) 73 {74 if (Request. category = RequestCategory. category1) 75 {76 // handle the request which category is Category1 77 request. isHandled = true; 78} 79} 80} 81 82 public class ConcreteHandler2: Handler 83 {84 public ConcreteHandler2 () 85 {86} 87 88 public ConcreteHandler2 (Handler successor) 89: base (successor) 90 {91} 92 93 protected override void OnHandle (Request request) 94 {95 if (request. category = RequestCategory. category2) 96 {97 // handle the request which category is Category2 98 request. isHandled = true; 99} 100} 101} 102 103 public class Client104 {105 public void TestCase1 () 106 {107 Request request1 = new ConcreteRequest1 (); 108 Request request2 = new ConcreteRequest2 (); 109 110 Handler handler2 = new ConcreteHandler2 (); 111 Handler handler1 = new ConcreteHandler1 (handler2); 112 113 handler1.Handle (request1 ); 114 handler1.Handle (request2); 115} 116} 117}