책임 떠넘기기(Chain of Responsibility) 패턴

책임 떠넘기기라는 단어는 부정적인 의미가 강하지만 꼭 필요한 경우도 있다.

어떤 요청이 발생했을 때 그 요청을 처리할 객체를 직접 결정할 수 없는 경우, 복수의 객체를 사슬(chain)처럼 연결해 두면, 그 객체의 사슬을 차례로 돌아다니면서 목적한 객체를 결정하는 방법을 생각할 수 있다.

이 패턴을 사용하면 ‘요청하는 쪽'과 ‘처리하는 쪽'의 연결을 유연하게 해서 각 객체를 부품으로 독립시킬 수 있다.

상황에 따라서 요청을 처리할 객체가 변하는 프로그램에도 대응할 수 있다.

다음 링크는 책임 떠넘기기 패턴의 예제 코드다.

GitHub - kkoon9/Java-Design-Pattern: Java 언어로 배우는 디자인 패턴 입문 예제 코드

책임 떠넘기기 패턴의 등장인물

Handler(처리자)의 역할 - Support

요구를 처리하는 인터페이스(API)를 결정하는 역할을 한다.

‘다음 사람'을 준비해 두고 자신이 처리할 수 없는 요구가 나오면 그 사람에게 떠넘기기를 한다.

물론 ‘다음 사람'도 Handler 역할을 수행한다.

ConcreteHandler(구체적인 처리자)의 역할 - 여러 Support들

요구를 처리하는 구체적인 역할을 한다.

Client(요구자)의 역할 - Main

최초의 ConcreteHandler 역할에 요구하는 일을 한다.

동적으로 사슬의 형태를 바꾼다

예제 코드에서는 Alice에서 Fred까지의 항상 고정된 순서로 되어 있다.

하지만 요구츨 처리하는 ConcreteHandler 역할의 객체 관계가 동적으로 변화하는 상황이 생길 수 있다.

책임 떠넘기기 패턴과 같이 위임에 의해 떠넘기기를 실행하고 있으면 상황의 변화에 따라서 역할을 재편할 수 있다.

예시로, 윈도우 시스템에서 사용자가 윈도우 상에 컴포넌트를 자유롭게 추가할 수 있는 경우로 이 패턴이 사용된다.

자신의 일에 집중할 수 있다.

각 ConcreteHandler들은 다른 Handler에 떠넘기는 기능을 구현할 필요없이 자신의 역할만 수행할 수 있다.

만약 책임 떠넘기기 패턴을 사용하지 않았다면 모든 ConcreteHandler에 다른 Handler에 떠넘기는 기능이 필요했을 것이다.

🤔
떠넘기기로 처리가 지연되지 않을까?

 

충분히 지연될 수 있다.

그러나 이것은 트레이드 오프의 문제다.

요구와 처리자의 관계가 고정적이고 처리 속도가 상당히 중요한 경우에는 이 패턴을 사용하지 않는 것이 좋다.

관련 패턴

• Composite 패턴
• Command 패턴