책임연쇄 — 단계가 계속 늘어나는 처리 흐름

• GoF 행동 패턴 정리 — 요청을 핸들러 체인에 흘려보내고, 각 핸들러가 처리하거나 다음으로 넘김
• 정리 계기: 단계가 정해진 처리 흐름에 중간 단계가 계속 추가되는 상황을 어떻게 다룰지
• 주안점: 단계 추가가 기존 코드 수정으로 번지지 않게 하는 구조

언제 필요한가

주문 처리 흐름을 예로 들면 처음엔 단순함.

주문 확인 → 수량 확인 → 배송지 확인 → 완료

여기에 요구사항이 붙는다 — 각 단계 사이에 유효성 검증, 캐싱 조회, 로깅이 들어가야 한다. 순차 호출로 짜여 있으면 그때마다 흐름 코드 본문을 고쳐야 한다.

구조

interface Handler {
  setNext(next: Handler): Handler;
  handle(req: Request): Result | null;
}

abstract class BaseHandler implements Handler {
  private next?: Handler;

  setNext(next: Handler) {
    this.next = next;
    return next;             // 체이닝으로 연결
  }

  handle(req: Request): Result | null {
    return this.next ? this.next.handle(req) : null;   // 못 다루면 다음으로
  }
}

// 클라이언트는 첫 핸들러에만 요청을 전달
chain.handle(request);

• 각 단계가 독립 클래스 — 단계 추가는 클래스 하나 추가 + 연결 한 줄
• 처리 순서 변경도 연결 순서만 바꾸면 됨

대가

• 디버깅이 어려움 — 요청이 어디서 멈췄는지 체인을 따라가야 함
• 처리 보장이 없음 — 아무도 안 받으면 조용히 끝남. 종단 핸들러를 두거나 미처리를 명시적으로 다뤄야 함
• 체인이 길어질수록 호출 깊이와 추적 비용이 함께 증가

정리

• 단계가 늘어날 것이 예상될 때 값을 하는 패턴. 고정된 3단계에는 과함
• 같은 발상을 실무에서 본 형태: 미들웨어 스택, 인터셉터 체인