기획자의 변심 : 기획자가 와서 위의 그림에서 할인 정책을 바꾸고싶다고 한다.
그러면 어떻게 해야하나?
*Service system에서 보통 서비스를 제공하기 위해 DB에 접근해야 한다. 이에 따라 DAO를 바라보게 된다. (즉, Service system안에 DAO들을 주입해줘야 한다)
SRP - 단일 책임 원칙을 잘 지켰는가?
OCP - 개방폐쇄의 원리를 잘 지켰는가? - 구현체만 바뀌는 다형성 이용
LisKov의 원리 - 그 역할 의미대로 잘 지켰는가?
ISP - 적절하게 역할에 맞게 인터페이스를 잘 쪼개야 한다
DIP - 의존관계 역전 - 인터페이스(역할)에 의존하게 해야한다.
역할과 구현을 충실히 분리해는가? 넵!
다형성도 활용하고, 인터페이스와 구현 객체를 분리했는가? 넵!
OCP, DIP같은 객체지향 설계 원칙을 충실히 준수했는가? → 그리 보이지만 사실 아니다
3.1) DIP → 위의 코드에서 의존관계를 분석해 보면, 인터페이스뿐만 아니라 구현체 클래스도 의존하고 있다는 것을 알 수 있다.
private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
인터페이스 - DiscountPolicy, 구현체 - RateDiscountPolicy 또는 FixDiscountPolicy
→ 실제 그림은 위와 같다 Interface와 Implementation 둘 다 의존하고 있다. (DIP 위반)
<aside> 💡 의문점이 들수 있다: 아니 도대체 뭐가 문제가 되는데!? 순간적으로 착각할수 있다 Interface를 의존하고 있고! 우린 구현체만 바꿔서 Service한테 알려준것뿐인데 이게 뭐가 문제지?
→ Serivce에 구현체의 의존관계가 생기는게 문제이다 우리는 구현체가 Interface만 바라보게하고 구현체만 Interface에 맞게 만들면 끝나야하는데, 바로 서비스구현체 안에서 Discount구현체를 새로 주입해줘야 하는게 문제가 된다. 이것이 OCP위반이다.
</aside>
즉, OCP는 구현체만 바뀌면 끝나야하는데 서비스 구현체에 주입을 또 해줬으니까 위반된거