[Design Pattern] 책임 연쇄 패턴(Chain of Reponsibility Pattern)에 대해 알아보자

Definition

책임 연쇄(Chain of Responsibility)는 일련의 핸들러를 따라 요청을 전달할수 있는 패턴이다. 요청을 받으면 각 핸들러는 요청을 처리할지 아니면 체인의 다음 핸들러로 전달할지 결정한다.

Behavioral Patterns

Situation

- 1개의 요청을 2개 이상의 객체에서 처리해야 할때

- 윈도우 시스템에서 마우스 클릭과 키보드 이벤트를 처리할 때 흔히 쓰인다.

- 프로그램이 다양한 방식으로 다양한 종류의 요청을 처리할 것으로 예상되지만 정확한 요청 유형과 순서를 미리 알 수 없는 경우

- 특정 순서로 여러 핸들러를 실행해야 하는 경우

Structure

Pros

- 요청을 보낸 쪽과 받는 쪽을 분리할 수 있다.

- 객체는 사슬의 구조를 몰라도 되고 그 사슬에 들어있는 다른 객체의 직접적인 레퍼런스를 가질 필요도 없으므로 객체를 단순하게 만들 수 있다.

- 사슬에 들어가는 객체를 바꾸거나 순서를 바꿈으로써 역할을 동적으로 추가하거나 제거할 수 있습니다.

Cons

- 요청이 반드시 수행된다는 보장이 없다. (사슬 끝까지 갔는데도 처리되지 않을 수 있다.)

- 실행 시에 과정을 살펴보거나 디버깅하기가 힘들다.

비슷한패턴

Chain of Responsibility, Command, Mediator, Observer는 요청의 발신자와 수신자를 연결하는 다양한 방법을 다룬다.

• Chain of Responsibility는 잠재적 수신자 중 하나가 처리할 때 까지 잠재적 수신자의 동적 사슬을 따라 순차적으로 요청을 전달한다.
• Command는 발신자와 수신자간의 단방향 연결을 설정한다.
• Mediator는 송신자와 수신자 간의 직접 연결을 제거하여 Mediator 객체를 통해 간접적으로 통신하도록 한다.
• Observer를 사용하면 수신기가 수신 요청을 동적으로 구독 및 구독 취소 할 수 있다.

Chain of Responsiblity는 종종 Composite와 함께 사용된다. 이 경우 리프 구성 요소가 요청을 받으면 모든 상위 구성 요소의 체인을 통해 객체 트리의 루트까지 전달할 수 있다.

 

Chain of Responsibility의 핸들러는 Command로 구현할 수 있다. 이 경우 요청으로 표시되는 동일한 컨텍스트 객체에 대해 다양한 작업을 실행할 수 있다. 

그러나 요청 자체가 Command 객체인 또 다른 접근 방식이 있다. 이 경우 체인에 연결된 일련의 서로 다른 컨텍스트에서 동일한 작업을 실행할 수 있다.

 

Chain of Responsiblity와 Decorator는 클래스 구조가 매우 유사하다. 두 패턴 모두 일련의 객체를 통해 실행을 전달하기 위해 재귀 구성에 의존한다. 그러나 몇가지 결정적인 차이점이 있다.

 

CoR 핸들러는 서로 독립적으로 임의의 작업을 실행할 수 있다. 또한 언제든지 요청을 더 이상 전달하지 않을 수 있다. 반면에 다양한 Decorator는 기본 인터페이스와 일관성을 유지하면서 객체의 동작을 확장할 수 있다. 또한 Decorator는 요청의 흐름을 중단할 수 없다.

헤드퍼스트 디자인패턴 개정판 - 에릭 프리먼
https://refactoring.guru/design-patterns/builder