Ch03. 스프링 핵심 원리 이해(객체 지향 원리 적용) - 새로운 할인 정책 개발

새로운 할인 정책을 확장해보자.

• 시나리오
  • 악덕 기획자: 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문 시 1000원을 할인해주고, 20000원 주문 시에 2000원을 할인해주는 거예요!
  • 순진 개발자: 제가 처음부터 고정 금액 할인은 아니라고 했잖아요.
  • 악덕 기획자: 애자일 소프트웨어 개발 선언 몰라요? “계획을 따르기보다 변화에 대응하기를”
  • 순진 개발자: … (하지만 난 유연한 설계가 가능하도록 객체지향 설계 원칙을 준수했지 후후)
  • 참고: 애자일 소프트웨어 개발 선언 https://agilemanifesto.org/iso/ko/manifesto.html

애자일 소프트웨어 개발 선언

• 새로운 정책 작성

  • 

    새로운 할인 정책

  • 인터페이스의 구현체를 갈아 끼우면 된다(객체지향적 설계를 잘 했기 때문)
• Test

  • 

    성공 테스트(10% 할인이 되어야한다)

  • 

    실패 테스트(실패 테스트도 중요하다)

  • 객체지향적으로 설계를 잘하였기 때문에 단일 책임으로서 테스트 하기 용이하다

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

클라이언트 코드의 수정이 필요하다

• 우리는 역할과 구현을 충실하게 분리했다. OK
• 다형성도 활용하고, 인터페이스와 구현 객체를 분리했다. OK
• OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했다
  • 그렇게 보이지만 사실은 아니다.
• DIP: 주문서비스 클라이언트( OrderServiceImpl )는 DiscountPolicy 인터페이스에 의존하면서 DIP를 지킨 것 같은데?
  • 클래스 의존관계를 분석해 보자. 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다.
    • 추상(인터페이스) 의존: DiscountPolicy
    • 구체(구현) 클래스: FixDiscountPolicy , RateDiscountPolicy
• OCP: 변경하지 않고 확장할 수 있다고 했는데!
  • 지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다! 따라서 OCP를 위반한다.
• 실제 의존관계

  • 

    실제 의존관계

  • 잘보면 클라이언트인 OrderServiceImpl 이 DiscountPolicy 인터페이스 뿐만 아니라 FixDiscountPolicy 인 구체 클래스도 함께 의존하고 있다. 실제 코드를 보면 의존하고 있다! DIP 위반
• 정책 변경

  • 

    정책 변경

  • 그래서 FixDiscountPolicy 를 RateDiscountPolicy 로 변경하는 순간 OrderServiceImpl 의 소스 코드도 함께 변경해야 한다! OCP 위반
• 어떻게 문제를 해결할 수 있을가?
  • 클라이언트 코드인 OrderServiceImpl 은 DiscountPolicy 의 인터페이스 뿐만 아니라 구체 클래스도 함께 의존한다.
  • 그래서 구체 클래스를 변경할 때 클라이언트 코드도 함께 변경해야 한다.
  • DIP 위반 추상에만 의존하도록 변경(인터페이스에만 의존)
  • DIP를 위반하지 않도록 인터페이스에만 의존하도록 의존관계를 변경하면 된다.
• 인터페이스에만 의존하도록 수정한다.

  • 

    인터페이스에만 의존하도록 수정한다.

  • 

    인터페이스에만 의존된다.

  • 실제 구현체를 정의하지 않았기에 NullPointException이 발생한다
• 해결방안
  • 이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy 의 구현 객체를 대신 생성하고 주입해주어야 한다