Design Model learning Summary (17) responsibility chain model

This series mainly records what the design pattern intends to be, what issues it wants to solve, and when it can be used; how it solves it, master its structure diagram, remember its key code; be able to think of at least two of its application instances, one in life and one in software; What are the advantages and disadvantages of this model, and what use scenarios are there, what should I pay attention to when using it.

 

 

17. Responsibility Chain Model

Intention: To avoid coupling between request senders and receivers, multiple objects may receive requests, connect these objects into a chain, and pass requests along the chain, until an object processes it.
Main Solution: The processor on the responsibility chain is responsible for processing requests. The customer only needs to send requests to the responsibility chain, and does not need to care about the request processing details and request transmission, therefore, the responsibility chain decouples the request sender and the request processor.
When to use: Filter multiple channels when processing messages
Solution: All intercepted classes implement unified interfaces.
Structure chart:

Key code: The Handler aggregates himself and determines whether the Handler is suitable in HanleRequest. If the conditions are not met, it will be passed down and the former set will be passed to the Handler.
Application Instance: 1. "drumming and spreading flowers" in A Dream of Red Mansions 2. Event bubbling in JS 3. Apache Tomcat processing in java web, Struts2 interceptor, and jsp servlet Filte
Advantages: 1. Reduce coupling. It decouples the request sender and receiver. 2. simplified the object. So that the object does not need to know the structure of the chain. 3. Increased the flexibility of assigning roles to objects. By changing members in the chain or mobilizing their order, you can dynamically add or delete responsibilities. 4. It is convenient to add a new request processing class.
Disadvantages: 1. the request cannot be guaranteed to be received. 2. the system performance will be affected, and it is not convenient for code debugging. It may cause loop calls. 3. It may not be easy to observe the features during running, which hinders debugging.
Use Cases: 1. Multiple objects can process the same request. The runtime determines which object processes the request. 2. If the receiver is not explicitly specified, submit a request to one of multiple objects. 3. A group of objects can be dynamically specified to process requests.
Notes: Many java web Applications