[스프링 핵심 원리 - 기본편] 스프링 핵심 원리 이해2 - 객체 지향 원리 적용(새로운 할인 정책 적용과 문제점)

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

정액 할인 정책 → 정률 할인 정책으로 변경

• OrderServiceImpl에서 다음 코드를 변경해야 함

// private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); 
private final DiscountPolicy discountPolicy = new RateDiscountPolicy();

문제점

• 역할과 구현을 충실하게 분리 OK
• 다형성도 활용하고, 인터페이스와 구현 객체를 분리 OK
• OCP, DIP와 같은 객체지향 설계 원칙을 충실히 준수했다
  • 그렇게 보이지만 사실은 아님
• 클래스 의존관계를 분석해보면 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존
  • 추상(인터페이스) 의존 : DiscountPolicy
  • 구체(구현) 클래스 : FixDiscountPolicy, RateDiscountPolicy

기대했던 의존관계

• DiscountPolicy 인터페이스에만 의존하는것을 기대

실제 의존관계

• OrderServiceImpl이 DiscountPolicy 인터페이스 뿐만 아니라, FixDiscountPolicy 구체 클래스도 함께 의존하고 있음 ⇒ 실제 코드 상 DIP 위반

정책 변경

• 중요: FixDiscountPolicy를 RateDiscountPolicy로 변경하는 순간 OrderServiceImpl의 소스 코드도 함께 변경해야 함 ⇒ OCP 위반

문제 해결

• 문제 원인 : 클라이언트 코드인 OrderServiceImpl은 DiscountPolicy의 인터페이스 뿐만 아니라 구체 클래스도 함께 의존
  • 그래서 구체 클래스를 변경할 때 클라이언트 코드도 함께 변경해야 함
  • DIP 위반 ⇒ 추상(인터페이스)에만 의존하도록 변경
• 해결 방안 : DIP를 위반하지 않도록 인터페이스만 의존하도록 의존관계를 변경하면 됨

인터페이스만 의존하도록 설계 변경

인터페이스만 의존하도록 코드 변경

// private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
private DiscountPolicy discountPolicy;

• 인터페이스에만 의존하도록 설계와 코드를 변경함
• 실행하면? ⇒ NPE 발생
  • 구현체를 지정하지 않고 코드를 실행했기 때문
• 해결 방안
  • 누군가 클라이언트인 OrderSerivceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해주어야 함

 

※ 본 게시글은 인프런의 스프링 핵심 원리 - 기본편(김영한)을 수강하고 정리한 내용입니다.