책임 연쇄 패턴

GOF의 디자인 패턴(책임 연쇄 패턴)

• 특정한 책임을 가지고 있는 클래스들이 연결되어 있는 구조로 무언가를 처리함
  
• 요청을 보내는 쪽과 처리하는 쪽을 분리하는 패턴
• 일반적인 코딩으로 패턴을 구성하면 클라이언트가 사용할 핸들러를 알아야만 사용할 수 있는 단점이 존재함
  → 책임 연쇄 패턴을 적용하면 클라이언트는 RequestHandler만 사용함
• 클라이언트는 구체적인 핸들러 타입을 모르게 하고, 그 뒷단에서 디자인을 구성하여 사용
  

※ 단일책임의 원칙(SRP) : 어떤 클래스가 변경되어야하는 이유는 어떤 한 가지 이유 때문이어야만 한다.

※ 사용 예시

RequestHandler

• 추상 클래스로 만듬
• 연쇄적으로 이어져야하기 때문에 이어질 수 있게끔 nextHandler를 생성자로 받아올 수 있게끔 함
• 요청 처리를 다음 핸들러에 위임할 수 있도록 함
• null이 아닐 때만 작업이 이어지도록 코딩함

PrintRequestHandler

• 화면 출력 요청 처리 핸들러
• 생성자 생성 후 오버라이딩 해서 요청의 본문 출력

AuthRequestHandler

• 인증 확인 처리

LoggingRequestHandler

• 로깅 처리

Client

• 작성된 위의 코드를 체인으로 연결해서 사용

※ 결론

• 클라이언트 부분의 메인 메소드를 참조해보면 이전에 만들었던 클래스 파일들을 체인으로 엮어서 더 이상 클라이언트가 본인이 어떤 핸들러를 사용해야할 지를 결정할 필요가 없어지고, 뒷단의 코딩에 따라서 코드가 반영되거나 넘어가거나 설정을 할 수 있음

※ 장점

• 클라이언트 코드를 변경하지 않고, 얼마든지 새로운 핸들러를 체인에다가 추가할 수 있고, 순서를 변경할 수 있다.
  (개방폐쇄의 원칙, OCP)
• 각각의 핸들러 마다 본인이 해야할 일만 가지고 있다.
  (단일 책임의 원칙, SRP)
• 체인을 다양한 방법으로 구성할 수 있다.

※ 단점

• 연쇄적으로 흘러가다 보니, 코드의 흐름이 많아지다 보니 디버깅이 어렵다.