다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없다.
새로 개발한 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체도 함께 변경해야 하는 문제점이 발생한다.
DiscountPolicy
뿐만 아니라, 구체 클래스인 FixDiscountPolicy
도 함께 의존하고 있다.private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
🚨 이는 DIP를 위반한다 🚨
애플리케이션을 하나의 공연으로 생각해보자
기존에는 남자 주인공 배우가 공연도 하고, 동시에 여자 주인공도 직접 초빙하는 다양한 책임을 지고 있다.
// OrderServiceImpl // 서버 구현 객체 생성 private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); // 실행 ...
AppConfig
를 통해 애플리케이션의 전체 동작 방식을 구성하기 위해, 구현 객체를 생성하고 연결하는 책임을 지게 된다.공연을 구성하고, 담당 배우를 섭외하고, 지정하는 책임을 담당하는 별도의 공연 기획자(AppConfig) 등장!
public class AppConfig { public MemberService memberService(){ return new MemberServiceImp(new MemoryMemberRepository()); } public OrderService orderService(){ return new OrderServiceImp(new MemoryMemberRepository(), new FixDiscountPolicy()); } }
public class AppConfig {
public MemberService memberService(){
return new MemberServiceImp(memberRepository());
}
private MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
public OrderService orderService(){
return new OrderServiceImp(memberRepository(), discountPolicy());
}
public DiscountPolicy discountPolicy(){
return new RateDiscountPolicy();
}
}