(스프링 핵심 원리 - 기본편) 3-(1)새로운 할인정책 개발, (2)새로운 할인 정책 적용과 문제점, (3)관심사의 분리

- 새로운 할인정책 개발

 

새로운 할인 정책 추가하려면 DIP, OCP를 지키지 못하는 문제 발생 => 이 문제를 해결하기 위해 여러 과정을 거치게 됨.

 

=> 새로운 할인 정책 : 기본 1000원 할인에서 10% 할인으로 변경하기

• 기존에 dicount package에 'RateDiscountPolicy' class를 만들고 기존의 DiscountPolicy Interface 를 implements 하기
• class를 작성하고 Ctrl +Shift + T 를 눌러 Test생성하기
• Test 작성하기 ( VIP라서 할인이 적용되는 경우와 적용되지 않는 경우 두가지 테스트) 

 

- 새로운 할인 정책 적용과 문제

• 새로운 할인 서비스를 적용하려면 OrderServiceImpl로 들어가야 함.
• OrderServiceImpl에서 선언된 FixDiscountPolicy 부분을 지우고 RateDiscountPolicy로 바꿔주기
• 이렇게 했을 때 문제점은 없는가? 
  • 역할 구현 분리 ? OK
  • 다형성 활용, 인터페이스와 구현 객체 분리 ? OK
  • OCP, DIP 같은 객체 지향 설계 원칙 충실히 준수? 그렇게 보이지만 사실은 아님.
    • DIP : 주문서비스 클라이언트는 DiscountPolicy 인터페이스에 의존하면서 DIP에 의존한 것처럼 보이는데 !! 
      • 클래스 의존관계를 분석해보면 추상(인터페이스)뿐만 아니라 구체적으로 구현된 클래스에도 의존하고 있음. => OderServiceImpl이 DiscountPolicy(인터페이스) 뿐만 아니라 FixDiscountPolicy 도 함께 의존하고 있음.
      • => DIP
    • OCP위반 : 변경하지 않고 확장할 수 있어야 한다.
      • 위반정책 변경하면 FixDiscountPolicy를 의존하던 부분을 RateDiscountPolicy를 의존하도록 변경해줘야 함.이게 바로 의존성인 것. OCP 위반
• 어떻게 해결하지 !!? 
  • DIP를 위반하지 않도록, 인터페이스만 의존하도록 변경하기.
  • Implement만 선언해두고 ! 
  • 누군가가 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해줘야 함.

 

- 관심사의 분리

• 각각의 인터페이스를 배역이라 생각하면 배역에 맞는 배우를 선택하는 건 누가 할까? 
• 기존에 짰던 코드는 각각의 역할(인터페이스)이 배우(구현체, 클래스)를 직접 초빙하는 거라 볼 수 있음.
• 관심사를 분리해야 함!
  • 배우(클래스)는 역할을 수행하는 거에만 집중할 수 있도록
  • 공연 기획자(역할에 맞는 배우를 지정하는 책임 담당)를 만들어야 함.
• AppConfig등장 : 공연기획자! 
  • 애플리케이션 전체 동작방식을 구성(config, 설정)

위처럼 하면 각 Service 클래스는 자기에게 주입되는 객체가 뭔지 전혀 모르게 됨. DIP 성립!

이를 '주입해준다' 라고 표현. 생성자 주입