[Spring 3.1] 템플릿과 콜백

 

 

 

템플릿은 코드 중에서 변하지 않는 부분을 변하는 부분으로부터 독립시켜 효과적으로 활용하는 기법을 말한다.

스프링 프레임워크에 적용된 템플릿 기법을 살펴보고 Data Access Object에 적용해보자.

 

DAO는 데이터베이스와 연결하는 부분이 필수적으로 포함된다.

데이터베이스와의 연결은 Connection Pool을 통해 이루어지고, 커넥션을 모두 사용했다면 반환해 다시 풀에 넣어 줘야 한다.

 

try {
    // connect..
} catch (Exception e) {
    
} finally {
    // close..
}

 

어떤 상황에서도 가져온 리소스를 반환할 수 있도록 try-catch-finally 구문을 사용한다.

제대로 작성한다면 커넥션 풀이 꽉 차는 현상은 막을 수 있지만.. DAO를 작성할 때 마다 try-catch-finally 구문을 작성하는건 쉽지 않고, 실수하기 쉽다. 

 

문제를 어떻게 해결해야 할까? 

 

변하지 않는 부분은 슈퍼 클래스에, 변하는 부분은 추상 메서드로 정의해 서브 클래스에서 해당 부분을 오버라이드해 사용하는 템플릿 메서드 패턴을 적용할 수 있지만, DAO 로직 별로 새로운 클래스를 만들어야 하고 확장 구조가 고정된다는 단점이 있어 문제를 해결하기에는 무리가 있다. 

 

 

 

 

전략 패턴을 사용해 보자.

 

오브젝트를 두 개로 분리하고 인터페이스에만 의존하도록 설계하는 패턴을 전략 패턴이라고 부른다.

 

 

 

 

변하지 않는 부분은 Context, 변하는 부분은 Strategy 인터페이스를 통해 구현한다.

필요에 따라 Context는 유지하면서 Strategy부분은 DI를 통해 클라이언트가 결정하도록 설계해 OCP 원칙을 깔끔하게 지켰다.

 

데이터베이스와 통신하는 부분을 예시로 들면, try/catch/finally 구문은 Context로, SQL 구문은 Strategy 인터페이스를 통해 구현한다. 

Context 부분을 별도의 클래스로 분리하고, DAO가 Context를 DI받아서 사용할 수 있게 설계하자. 

 

여기서 인터페이스를 도입 할 수도, 도입하지 않을 수도 있는데.. 인터페이스를 도입하지 않더라도 DI를 사용하는 편이 합리적이다.

DI를 사용해 싱글톤을 유지할 수 있고, 다른 요소가 이미 DI 받고 있는 상황이라면 DI 받아야 기존의 DI를 유지할 수 있기 때문이다.

 

굳이 빈으로 등록해 스프링을 통한 DI를 구현하는 것 보다 코드를 통해 DI 받는 방법이 더 괜찮다고 생각될 수 있다.

 

 

 

스프링을 사용하는 경우 런타임 시점 이전에 구체적인 클래스와의 관계가 설정에 노출된다는 단점이 있다.

코드를 통해 DI 받는 경우 싱글톤을 사용할 수 없고 별도로 코드를 작성해야 해 오버헤드가 발생한다.

 

두 방법 중 상황에 따라 적절한 방법을 선택하자. 인터페이스를 도입하는 것도 좋은 방법이다.

 

이렇게 변하지 않는 부분을 템플릿으로, 변하는 부분을 익명 내부 클래스를 통해 만들어지는 부분을 콜백으로 설정하는 부분을 템플릿/콜백 패턴이라고 부른다.

 

 

 

DI 방식의 전략 패턴으로 생각하면 된다.

핵심은 변하는 것과 변하지 않는 것들의 분리이고, 변하지 않는 부분은 유연하게 사용할 수 있도록 설계하는 부분이다.

작업 흐름이 고정되어있고 자주 반복된다면 중복되는 부분을 어떻게 분리할 수 있는지 생각해보자. 

 

중복되는 부분은 메서드로, 메서드에서 변경이 필요한 부분은 인터페이스를 도입해 전략 패턴을 사용하고, 해당 부분이 많이 사용된다면 템플릿/콜백 패턴을 도입하고... 이런 흐름이다.

 

스프링도 JdbcTemplate 등 템플릿/콜백 패턴이 적용된 api를 제공한다. 개념을 확실히 이해하고 api를 사용하자.