Chain of Responsibility Pattern - Design Pattern

1. Definition

As the name suggests, the Chain of Responsibility Pattern creates a chain of receiver objects for a request. This pattern decouples the sender and receiver of the request given the type of the request. This type of design pattern is a behavioral pattern.

In this pattern, typically each receiver contains a reference to another receiver. If an object cannot handle the request, it passes the same request to the next recipient, and so on.

Intent: To avoid the coupling of the request sender and the receiver, make it possible for multiple objects to receive the request, connect these objects into a chain, and pass the request along this chain until an object processes it.

Main solution: The processor on the responsibility chain is responsible for processing the request. The customer only needs to send the request to the responsibility chain, and does not need to care about the processing details and delivery of the request. Therefore, the responsibility chain will send the request to the request processor. decoupled.

Usage scenarios:  1. There are multiple objects that can handle the same request, and the specific object that handles the request is automatically determined at runtime. 2. Submit a request to one of multiple objects without explicitly specifying the receiver. 3. A group of objects can be dynamically specified to process requests.

Second, the advantages and disadvantages

Advantages:  1. Reduce the degree of coupling. It decouples the sender and receiver of a request. 2. The object is simplified. So that the object does not need to know the structure of the chain. 3. Enhance the flexibility of assigning responsibilities to objects. By changing the members in the chain or mobilizing their order, it is allowed to dynamically add or delete responsibilities. 4. It is very convenient to add a new request processing class.

Disadvantages:  1. There is no guarantee that the request will be received. 2. The system performance will be affected to a certain extent, and it is not convenient to debug the code, which may cause circular calls. 3. It may not be easy to observe the characteristics of the runtime, which hinders debugging.

3. My own understanding

First understand the chain of the chain of responsibility, which is the linked list structure. We encapsulate the request (responsibility) we want to process. The encapsulated class has a pointer of its own type, and this class must have a processing method. In this method to call the processing method of the next responsible person through the pointer, thus achieving the concatenation of the entire chain of responsibility.

4. Code implementation

data class Responsibility(var request : String?)

abstract class Chain{

    var chain : Chain? = null

    abstract fun deal(responsibility: Responsibility)

}

class Chain1 : Chain(){

    override fun deal(responsibility: Responsibility) {
        responsibility.request += "----Chain1----"
        println(responsibility.request)
        chain?.deal(responsibility)
    }

}

class Chain2 : Chain(){

    override fun deal(responsibility: Responsibility) {
        responsibility.request += "-----Chain2-----"
        println(responsibility.request)
        chain?.deal(responsibility)
    }

}

class Chain3 : Chain(){

    override fun deal(responsibility: Responsibility) {
        responsibility.request += "Chain3"
        println(responsibility.request)
        chain?.deal(responsibility)
    }

}

fun main() {

    val chain1 = Chain1()
    val chain2 = Chain2()
    //把链连上
    chain1.chain = chain2
    val chain3 = Chain3()
    //把链连上
    chain2.chain = chain3
    
    chain1.deal(Responsibility("Start:"))

}

Guess you like

Origin blog.csdn.net/m0_37707561/article/details/127477201