dev.Log
템플릿 메서드 패턴 본문
좋은 설계는 변하는 것과 변하지 않는 것을 분리하는 것이다.
이 둘을 분리해서 모듈화해야한다.
Template Method Pattern은 이런 문제를 해결하는 디자인패턴이다.
public abstract class AbstractTemplate {
public void execute() {
long startTime = System.currentMillis();
call(); //상속
long endTime = System.currentTimeMillis();
long resultTime = endTime - startTime;
log.info("resultTime={}", resultTime);
}
protected abstarct void call();
}
@Slf4j
public classs SubClassLogic wextends AbstractTemplate {
@Override
protected void call() {
log.info("비즈니스로직1 실행");
}
}
@Test
void templateMethod() {
AbstractTemplate template1 =. new SubClassLogic();
template1.execute();
AbstractTemplate template2 =. new SubClassLogic2();
template2.execute();
}
익명내부클래스 사용하기
@Test
void templateMethodV2() {
//추상클래스를 상속받은 클래스를 바로 만들 수 있음
AbstractTemplate template1 = new AbstractTemplate() {
@Override
protected void call() {
log.info("비즈니스 로직실행");
}
}
template1.execute();
}
부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다.
이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다. 결국 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다.
"하지만"
템플릿 메서드 패턴은 상속을 사용한다. 따라서 상속에서 오는 단점들을 그대로 안고간다. 특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다. 이것은 의존관계에 대한 문제이다. 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는다.
그럼에도 불구하고 템플릿 메서드 패턴을 위해서 자식클래스는 부모클래스를 상속 받고 있다.
상속을 받는 다는것은 특정 부모 클래스를 의존하고 있따는 것이다. 지식 클래스의 'extends' 다음에 바로 부모 클래스가 코드상에 지정되어 있다. 따라서 부모 클래스의 기능을 사용하든 사용하지 않든 간에 부모 클래스를 강하게 의존하게 된다. 여기서 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀 있다는 뜻이다.
자식 클래스의 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는데, 부모 클래스를 알아야한다. 이것은 좋은 설계가 아니다. 그리고 이런 잘못된 의존관계 떄문에 부모클래스를 수정하면, 자식 클래스에도 영향을 줄 수가 있다.
추가로 템플릿 메서드 패턴은 상속 구조를 사용하기 때문에, 별도의 클래스나 익명 내부 클래스르 만들어야 하는 부분도 복잡하다.
지금까지 설명한 이런 부분들을 더 깔끔하게 개션하려면 어떻게 해야될까?
템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴이 바로 "전략패턴(Strategy Pattern)"
이다.
'BACKEND.* > JAVA' 카테고리의 다른 글
템플릿 콜백 패턴 (0) | 2024.05.31 |
---|---|
전략 패턴 (0) | 2024.05.31 |
동시성제어 - ThreadLocal (0) | 2024.05.29 |
Virtual Thread vs Thread (1) | 2024.04.10 |
Stream (0) | 2022.10.08 |