chain_of_resp.md

책임 연쇄 패턴

책임 연쇄 패턴은 핸들러들끼리 체인을 따라서 요청을 전달할 수 있게 해주는 디자인 패턴입니다.

예를 들어 Request(유저 정보)객체를 인자로 받는, LoggingHandler(유저 정보를 로깅하는 핸들러), AuthHandler(로그인 여부 인증 핸들러)의 두개의 핸들러가 있다고 해봅시다.

Client가 LoggingHandler를 통해 Request를 받아 정보를 로깅하기전 로그인 여부를 인증해야하는 과정을 밟아야한다면 클라이언트단에서 if문으로 검증해야할 것입니다. (혹은 데코레이터 패턴처럼 인자로 RequestHandler(핸들러들의 부모클래스)를 인자로 받아 생성하게 해서 인증 인가를 대신할 수도 있긴하다.) 그러니 이러한 Handler들이 여러개가 있다면 클라이언트단에서 핸들러를 사용하는 로직은 커질 수 밖에 없을 것 입니다.

여기서 해결 방법으로는 각 핸들러들은 chain(그 다음 행위를 수행할 핸들러)를 필드를 갖고(생성자를 통해 주입받음) 자신의 작업을 처리한 후 chain을 호출하는 방식을 사용할 수 있습니다.

이렇게된다면 원하는 작업들을 체인으로 마음대로 조정, 커스텀할 수 있습니다.

예제

class Client {

    fun main() {
        val requestHandler = LoggingHandler(AuthHandler(null))
        requestHandler.doWork()
    }
}

위와 같이 마지막 핸들러에서는 null을 전달해 다음 체인을 지정하지 않게 할 수 있습니다.

장점

장점으로는 여러가지 로직들을 마음대로 커스텀, 구성할 수 있어 기능 추가에 용이합니다.

단점으로는 디버깅이 힘듭니다. (인자로 여러개의 핸들러들을 불규칙하게 넣기때문에)

스프링, 스프링부트에서 이러한 책임 연쇄 패턴을 찾아볼 수 있는데 대표적으로 Filter, SecurityConfig가 있습니다.

Filter 클래스의 chain.doFilter()가 다음 작업으로 보내겠다는 뜻이며

SecurityConfig에서 http.어쩌구저쩌구.and().filterAfter()와 같이 다음 필터들을 등록한다거나 그러한 로직도 책임 연쇄 패턴으로 볼 수 있습니다.