디자인 패턴 : 연쇄 책임 패턴 (Chain Of Responsibility)

연쇄 책임 패턴 

• 클라이언트의 요청에 대한 처리를 하나의 객체가 하는 것이 아닌, 여러개의 처리 객체들로 나누고 사슬로 묶어 연쇄적으로 처리하는 방식
• 처리 객체들은 핸들러(Handler)라고 불리며 자신의 기능만큼만 요청을  처리하고(혹은 처리가 불가능하다면) 다음 체인으로 연결을 떠넘긴다. 
• if-else 문들을 최적화하는데에 있어서 애용되는 패턴
• 체인 연결을 동적으로 처리할 수도 있음

장점

• 클라이언트가 핸들러들의 내부 구조를 알 필요가 없음
• 새로운 요청에 대한 처리 객체 생성이 편해짐(각각의 체인마다 역할이 있으므로)
• 핸들러를 체인에 동적으로 추가하거나, 변경할 수 있어 유연해진다.
• 요청의 호출자와 수신자를 분리시킬 수 있음

단점

• 디버깅 및 테스트가 어려워질 수 있다.
• 체인 끝까지 갔는데도 처리되지 않는 경우가 있다.
  이 경우 '기본 핸들러'를 추가하여 기본 동작을 정의할 수도 있음

if else문을 각각의 핸들러로 만들고 처리하는 방식이므로 자세한 예시는 적지 않았다. 

다만 handler라는 interface 나 abstract 클래스에서 nextHandler를 설정하는 생성자가 있어야 한다

예를 들어,

 public Handler setNext(Handler handler) 
 {
        this.nextHandler = handler;
        return handler; 
 }

출처: https://inpa.tistory.com/entry/GOF-💠-Chain-Of-Responsibility-패턴-완벽-마스터하기 [Inpa Dev 👨‍💻:티스토리]

 

return을 해준 것은, 메서드 체인의 구성을 위해서 그대로 반환한 것이다. 

그리고 다음과 같이 자식 핸들러에서 구성될 메서드와, 요청을 처리할 메서드를 구현한다.

요청을 처리할 메서드에서는 자식 핸들러에서 구성될 메서드를 처리하고, 이후 nextHandler가 있다면 재귀적으로 nextHandler의 실행을 반복한다.

  protected abstract void process(String url);

    // 핸들러가 요청에 대해 처리하는 메서드 
    public void run(String url) {
        process(url);

        // 만일 핸들러가 연결된게 있다면 다음 핸들러로 책임을 떠넘긴다
        if (nextHandler != null)
            nextHandler.run(url);
    }

출처: https://inpa.tistory.com/entry/GOF-💠-Chain-Of-Responsibility-패턴-완벽-마스터하기 [Inpa Dev 👨‍💻:티스토리]

 

 

유니티와 접목시켜서 정리하며 첨언해보자면, 책임 연쇄 패턴이란 결국

요청의 처리를 여러 객체(핸들러)로 나누고 체인 형태로 연결하여 순차적으로 처리하는 디자인 패턴이다.

각 핸들러는 자신이 처리할 수 있는 요청만 처리하고, 나머지는 다음 핸들러로 넘긴다.

 

호출자는 요청을 보내는 주체이며 유니티에서는 클릭, 충돌 처리 등의 요청을 보낸다.

수신자는 이 요청을 받아 처리하는 핸들러들이며 체인 형태로 연결되어 있다.

여러 장점과 단점이 있고 유니티에서는 UI 이벤트 처리, 충돌 처리, 게임 로직 등에 사용된다.

 

 

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-Chain-Of-Responsibility-%ED%8C%A8%ED%84%B4-%EC%99%84%EB%B2%BD-%EB%A7%88%EC%8A%A4%ED%84%B0%ED%95%98%EA%B8%B0

💠 Chain Of Responsibility 패턴 - 완벽 마스터하기

 

 

 

++ 추가 ++

스크립터블 오브젝트로 핸들러를 만들고, ChainContext 스크립트를만들어 게임 씬에 배치하고 첫 번째 핸들러를 갖게 하면, 인스펙터 상에서 체인 구성을 시각화 할 수 있다. 이를 통해 이와 같은 기능들에 도전해볼 수 있다.