Closed sootudio closed 6 months ago
템플릿 메소드 패턴에서는 - 설계 레벨에서 어떤 기능을 사용할 지 미리 정해짐. 전략패턴처럼 인터페이스를 쓰면 - 실행 시간에 클라이언트가 어떤 전략을 사용할 지 선택했을 때 생성되기 때문에 더 유연성이 있다. => 클래스가 하나 더 생기느냐 아니냐에서 장단점이 갈리는 것이 아니라, 클라이언트가 UserDao에 대한 책임이 없기 때문에 설계 시점에서의 유연성이 올라가기 때문에 전략 패턴을 사용하는 것이다.!
<질문 늦게 올려서 죄송합니다...>
책에서, deleteAll() 메소드에서 변하지 않는 부분(try-catch)과 변하는 부분 (c.prepareStatement)을 분리하기 위해 템플릿 메소드 패턴을 이용하여 다음과 같이 만들었지만,![image](https://github.com/SSAFY11th-book-study/book-study/assets/83462874/7cf3d735-0b38-44b8-a61c-5e48d91d629a)
DAO 로직마다 새로운 클래스를 만들어야 한다는 단점이 있기 때문에, 전략 페턴을 사용하고, DI 적용을 하여 클라이언트와 컨텍스트를 분리했습니다.![image](https://github.com/SSAFY11th-book-study/book-study/assets/83462874/248bfb21-1f7f-4b51-9cab-43aa43da1325)
이 부분을 읽으며, 위의 그림 같은 전략 패턴 구조 역시 새로운 DAO 로직에 적용하기 위해서는 ConcreteStrategyA, ConcreteStrategyB와 같이 전략을 사용할 클래스를 새로 만들어야 한다고 이해했는데, 이렇게 하면 템플릿 메소드 패턴을 사용했을 때 지적했던, DAO로직마다 새로운 클래스를 만들어야 한다는 문제가 여전히 존재하는 것이 아닌가? 라는 생각이 들었습니다.