본문 바로가기
Theory/Design Pattern

Chain Of Responsibility Pattern

by y.j 2022. 5. 10.
728x90

Chain Of Responsibility Pattern

request가 있을 때 request를 다룰 수 있는 기회를 특정 object에게 준다. 이러한 object가 연결되어 있는 chain에 reuqest를 넣고, object들이 이 request를 다룰 때마다 chain을 통과하는 방식을 사용한다.

어떻게 request의 송신자와 수신자가 서로 의존하게 되는 것을 막을 수 있을까?
어떻게 request를 여러 object를 통하여 처리 할 수 있을까?

위 그림처럼 Receiver object들을 여러개 묶어 chain으로 만들어 놓고 요청에 대해서 각 처리하도록 한다. 

 

Solution

Handler를 다룰 수 있도록 상속받은 Receiver class를 만든다.

public class Receiver1 extends Handler {
    public Receiver1(Handler successor) {
        super(successor);
    }

    @Override
    public void handleRequest() {
        if(canHandleRequest()) {
            System.out.println("Receiver1 : Handling the request ...");
        }
        else {
            System.out.println("Receiver1 : Passing the request along the chain ...");
            super.handleRequest();
        }
    }
}

그리고 compile-time에 이것을 chain으로 엮어 생성한다.

public class ChainOfResponsibilityTest {
    @Test
    public void chainOfResponsibilityTest() {
        Handler handler = new Receiver1(new Receiver2(new Receiver3()));

        System.out.println("Issuing a request to a handler object ... ");
        handler.handleRequest();
    }
}

 

Advantages

• receiver로부터 sender를 분리시킨다.

 - 특정 chain handler에 request를 전송시키기 때문에 sender와 reciever가 서로 분리된다.

• run-time에 특정 chain을 추가하거나 제거하기 쉽다. .

Disadvantages

• Successor chain은 복잡하다.

 - 시스템의 구조에 대해서  정의를 제대로 하지 않는다면, chain을 유지하거나 구현하기 힘들다.

 

[전체 코드]

https://github.com/jKyounju/adapterPatterns/tree/master/src/BehavioralPattern/ChainOfResponsibilityPattern

728x90

'Theory > Design Pattern' 카테고리의 다른 글

Interpreter Pattern  (0) 2022.05.14
Command Pattern  (0) 2022.05.12
Flyweight Pattern  (0) 2022.05.09
Facade Pattern  (0) 2022.05.09
Decorator Pattern  (0) 2022.05.08

댓글