Contact 1997

(스프링) HandlerInterceptor vs WebRequestInterceptor

- 추상화된 인터페이스가 두 개가 존재한다.

- 메소드 개수가 동일한다. preHandle()/postHandle()/afterCompletion(). 호출 전/호출 후/처리완료 후. 

- DispatcherServlet 은 핸들러 매핑을 통하여 적절 핸들러 메소드를 찾아, HandlerAdapter 를 사용, 실제 메소드를 호출한다. (MVC 기준에서 AbstractHandlerMethodAdapter 와 RequestMappingHandlerAdapter 를 이용한다.) 이때 HandlerInterceptor 가 있으면 전처리/후처리를 커스텀하게 작성할 수 있다.

- MVC 방식에선 HandlerInterceptor 를 이용하지만 스프링 모든 요청에 대해서 처리를 하려고 한다면 WebRequestInterceptor 를 이용한다. 왜냐하면 WebRequest 라는 좀 더 스프링레벨의 추상화 객체를 이용하기 때문이다. 그러나 두 인터셉터의 동작방식은 비슷하기에 전자를 사용해도 상관없다. 전자의 경우 메소드 시그니처가 request, response, handler 등 디테일하게 있어서 세밀한 처리가 가능하다.

(이펙티브 코틀린) has-a 관계

- has-a 컴포지션이 안전하고 명시적이다.

- 명확한 is-a 관계일 때 상속을 이용하자.

- 인터페이스를 상속받아 모든 메소드를 호출하는데 일부는 처리하지 않는 경우가 있다. 이럴때는 상속보단 컴포지션을 사용한다.

- 슈퍼클래스 동작을 서브클래스에서 깨버리기 때문이다. (인터페이스 분리 원칙을 깨트린다.)

- 컴포지션은 만능은 아니다.

슈퍼클래스 동작을 서브클래스에서 깨버리는 코드 예시.

import java.lang.UnsupportedOperationException

interface OrderService {
    fun ordered(): Boolean
}

class SnackOrderService: OrderService {
    override fun ordered(): Boolean {
        throw UnsupportedOperationException("SnackOrderService 는 지원하지 않습니다.")
    }
}

class CarOrderService: OrderService {
    override fun ordered(): Boolean {
        return true
    }
}