일반적으로 성격이 다른 코드들은 가능한 분리하여 관리하고
하나의 목적을 위해 서로 긴밀하게 연관되어 동작하는 응집력이 강한 코드들은 한 군데 모아 관리하는 것이 유지보수적인 측면에서도 유리하다.
구체적인 구현과 내부의 전략 패턴, 코드에 의한 DI나 익명 내부 클래스 등의 기술은 최대한 감춰두고 외부에는 꼭 필요한 기능을 제공하는 단순한 메서드들만 노출해주어야 한다.
클라이언트는 콜백함수를 생성하고 템플릿에게 전달한 후 템플릿에서 레퍼런스를 콜백함수에게 전달하여 코드 진행이 되는데 이 때 바인딩 파라미터의 개수가 일정하지 않다면 가변인자로 정의하여 유연하게 대처하는 것이 좋다.
고정된 작업 흐름을 가지고 있으며 반복되는 코드들이 있다면 분리하는 시도를 하고 일부 작업을 필요에 따라 바꾸어 사용해야 한다면
중간에 인터페이스를 두고 분리하여 전략 패턴을 적용하고 DI로 의존관계를 관리하도록 만든다.
하지만 바뀌는 부분이 한 애플리케이션 안에서 동시에 여러 종류가 만들어질 수 있다면 이번엔 템플릿/콜백 패턴을 적용해볼것을 고려해야한다.
가장 전형적인 템플릿/콜백 패턴의 후보는 try/catch/finally 블록을 사용하는 코드이다.
이들은 중첩되어 사용하면 스파게티 코드가 되기 쉽기 때문에 주의하자.
템플릿/콜백 패턴을 적용할 때 고민해야할 사항은
1. 템플릿에 담을 반복적인 작업흐름은 무엇인지
2. 템플릿이 콜백에게 전달해 줄 내부의 정보는 무엇인지
3. 콜백이 템플릿에게 돌려줄 내용은 무엇인지이다.
특성에 따라 콜백의 인터페이스를 정의해야하기 때문에 각각에게 전달하는 내용이 무엇인지 설계하는 것이 중요하다.
