[Design Pattern] Chain of Responsibility

Chain of Responsibility Pattern

Chain of Responsibility Pattern은 요청을 처리할 수 있는 기회를 여러 객체들에게 부여함으로써 그들 간의 결합도를 없애주는 패턴입니다.

• 복수의 Object를 사슬처럼 연결해주면, 그 오브젝트의 사슬을 차레대로 돌아다니면서 목적한 Object를 결정하는 방법입니다.
• responsibility 개념을 갖는 모듈들에 체인을 만드는 Pattern 입니다.

• chain of responsibility pattern이 아닌 결제 예제
  • 클라이언트 코드에서 결제 요청을 발행 합니다.
  • 결제 요청 안에는 결제방법과 금액이 존재합니다.
  • 결제 방법에는 cash, credit card, debit card 등이 있습니다.
  • 결제 요청을 처리하는 함수나 클래스가 있어야 하는데 새로운 결제 방법을 추가하고 수정할 때마다 코드의 길이가 길어지고 복잡해집니다.

• 결제 방법에 따라 모듈을 만드는 것부터 시작합니다.
  • Cash Handler, Credit Card Handler, Debit Card Handler를 생성합니다.
  • 각 Handler를 체인으로 묶습니다.

Cash Handler를 만나고 결제 방법이 Cash인 것을 확인하고 바로 결제를 완료합니다.

• 결제 방법이 Debit Card이므로 Cash Handler, Credit Card Handler가 처리할 수 없으므로, 다음 Handler에게 넘기고 결국 Debit Card Handler가 처리합니다.

---

Example: 결제 시스템

Base class

class Handler:
    def __init__(self):
        self.next_handler = None

    def setNext(self, handler):
        self.next_handler = handler

    def handle(self, req):
        if self.next_handler:
            return self.next_handler.handle(req)
        print("All handlers failed")
        return None

• __init__
  • 내부에 다음 Handler를 가리키는 next_handler 가 존재합니다.
• setNext()
  • 다음 Handler인 next_handler를 설정합니다.
• handle()
  • 결제 요청이 들어오면 실행시키는 함수입니다.
  • Argument로 request 정보가 있습니다.
  • 다음 Handler가 존재하면 next_handler의 handle 함수를 실행합니다.
  • 존재하지 않을 경우, None을 Return 합니다.

 

Cache Handler

class CashHandler(Handler):
    def handle(self, req):
        if req['method'] == 'cash':
            print(f"processing cash {req['amount']} won")
        else:
            print(f"CashHandler cannot process")
            super().handle(req)

class CreditCardHandler(Handler):
    def handle(self, req):
        if req['method'] == 'creditCard':
            print(f"processing creditCard {req['amount']} won")
        else:
            print(f"CreditCardHandler cannot process")
            super().handle(req)

class DebitCardHandler(Handler):
    def handle(self, req):
        if req['method'] == 'debitCard':
            print(f"processing debitCard {req['amount']} won")
        else:
            print(f"DebitCardHandler cannot process")
            super().handle(req)

• CashHandler - handle()
  • Base class의 handle함수를 override 합니다.
  • 결제 방법이 'cash'일 경우, 결제를 처리합니다.
  • 'cash'가 아닐 경우, 처리할 수 없다고 출력 후 Base class의 handle()함수를 부르기 위해 super().handle를 호출하고 req를 인자로 넘겨줍니다. (다음 Handler에게 넘겨주는 부분)
• CreditCardHandler
  • CashHandler와 동일한 방식
  • Method가 "creditCard"일 경우 처리
• DebitCardHandler
  • CashHandler와 동일한 방식
  • Method가 "debitCard"일 경우 처리

 

cash_handler = CashHandler()
creditcard_handler = CreditCardHandler()
debitcard_handler = DebitCardHandler()

cash_handler.setNext(creditcard_handler)
creditcard_handler.setNext(debitcard_handler)

• 각 Handler의 Object를 생성합니다.
• setNext 함수를 통해 세 개의 Handler를 체인처럼 묶습니다.

 

payment = {
    "method": "cash",
    "amount": 10000
}

cash_handler.handle(payment)

• 결제 방식이 "cash"인 payment를 생성합니다.
• 첫 번째 모듈인 CashHandler에서 바로 처리합니다.

 

payment = {
    "method": "debitCard",
    "amount": 10000
}

cash_handler.handle(payment)

• 결제 방식이 "debit card"인 payment를 생성합니다.
• CashHandler와 CreditCardHandler에서는 처리를 못하고 DebitCardHandler에서 처리됩니다.

 

payment = {
    "method": "paypal",
    "amount": 10000
}

cash_handler.handle(payment)

• 결제 방식이 "paypal"인 payment를 생성합니다.
• 세 가지 Handler 모두 해당 안되므로 처리하지 못합니다.

---

개념 확장

등장인물

• Handler: 요구를 처리하는 인터페이스를 결정하는 역할을 합니다.
  • '다음 담당자'를 준비해 두고 자신이 처리할 수 없는 요구가 나오면 그 담당자에게 떠넘기기를 합니다. 물론 '다음 담당자'도 Handler 역할을 합니다.
• ConcreteHandler: 요구를 처리하는 구체적인 역할을 합니다.
• Client: 최초의 ConcreteHandler 역할에 요구하는 일을 합니다.

 

요구하는 사람과 요구를 처리하는 사람을 유연하게 연결

• Client는 최초로 만나는 담당자에게 요구하며, 뒷일은 사실 안으로 그 요구가 전달되어 적절한 다른 담당자에 의해 처리됩니다.
• 만약 Chain of Responsibility를 사용하지 않으면 ‘이 요구는 이 담당자가 처리해야 한다’라는 정보를 누군가 중앙집권적으로 가지고 있어야 합니다.
• 이러한 정보를 ‘요구하는 사람’에게 갖게 하는 것은 현명한 방법이 아닙니다.
  • 요구하는 사람이 담당자들의 역할 분담까지 자세하게 알아야 한다면 부품으로서의 독립성이 훼손되기 때문입니다.

 

동적으로 사실의 형태를 변경

• 요구를 처리하는 ConcreteHandler 역할의 오브젝트 관계가 동적으로 변화하는 상황이 있을 때, ConcreteHandler 역할을 재편할 수 있습니다.
• 만약, CoR 패턴을 사용하지 않고 프로그램 안에 ‘이 요구라면 이 담당자’라는 대응 관계가 고정적으로 기술되어 있으면 프로그램 실행 중에 처리자를 변경하기 어렵습니다.

자신의 일에 집중

• 떠넘기기는 부정적 의미가 강하지만, 각 오브젝트는 자신의 일에 집중할 수 있다는 의미가 되기도 합니다.
• 각각의 ConcreteHandler 역할들이 사용해야 할 처리에 대한 것들이 고유한 내용으로 집중할 수 있게 됩니다.

 

떠넘기기로 인하여 처리가 지연되지 않을까?

• 해당 구조는 틀림없이 유연성은 높을지 모르지만 처리가 지연될 것 같다는 생각이 듭니다.
• 누가 요구를 처리할 지 미리 정해져 있고 그 담당자가 바로 처리하는 경우와 비교하면 지연되는 부분도 있을 것입니다. 그러나 일종의 트레이드 오프로 봐야 합니다.
• 요구자와 처리자의 관계가 고정적이고 처리 속도가 상당히 중요한 경우 CoR 패턴을 굳이 사용할 이유가 없을 것입니다.