Section3 OCP, DIP가 지켜지지 않은 코드
인프런 강의 中
김영한 강사님의 '스프링 핵심 원리' 내용을 정리했습니다.
이전 시간까지 주어진 요구사항을 토대로 도메인을 설계하고 코드를 작성해보았다. 그리고 코드를 실행시켜보며 원하는 값이 반환되는지 확인했다. 이번 Section3부터는 김영한 강사님의 강의와 같이 할인 정책을 변경해보며 기존 코드에 어떤 문제가 있고 코드를 어떻게 리팩토링해야 좋은 객체 지향 설계를 할 수 있는지 정리해보겠다. Let's make it happen!!!
변경된 할인 요구사항
- 주문 서비스 개발을 진행하는 중 할인 정책을 개발해야 한다.
- 기존 정책인 정액(고정) 할인 정책에서 VIP 등급이라면 구매한 가격에 10% 할인이 적용되는 정률 할인 정책으로 서비스를 변경해야 한다.
정률 할인 정책 구현체 개발
할인 정책은 처음부터 역할과 구현으로 분리해서 개발을 했기 때문에 새로운 정책을 개발할 때 할인 정책의 역할(DiscountPolicy Interface)을 상속받으면 된다. 그럼 새로 개발한 정률 할인 정책 구현체(RateDiscountPolicy)를 사용할 수 있도록 코드를 수정해보자.
주문 서비스 구현체에서 할인 정책 구현체(FixDiscountPolicy)를 new로 생성했기 때문에 여기서 할인 구현체를 변경해주면 원하는 할인 서비스를 사용할 수 있다.
이때!! 확장에는 열려 있으나 변경에는 닫혀야 한다는 OCP(개발-폐쇄)원칙이 위반된다. *사용 영역의 클라이언트 코드가 수정되었기 때문이다.
new RateDiscountPolicy()로 객체를 생성하는 순간 DIP(의존역전) 원칙도 위반된다. 왜냐하면 서비스 구현체는 할인 정책 인터페이스에만 의존해야 되는데, 할인 정책 구현제에도 의존하기 때문이다. 그리고 사실 DIP 원칙을 위반했기 때문에 OCP 원칙이 자연스레 위반되어진 것이다. 아래 다이어그램을 통해 더 쉽게 이해해보자.
※ 설명글에서 의존한다는 말이 이해가 되지 않을 수 있다. 여기서 의존한다는 건 쉽게 생각해서 해당 클래스가 다른 클래스를 알고 있다고 생각하면 된다. 위 코드를 예로 들자면, OrderServiceImpl이라는 구현체(클래스)에서
private final DiscountPolicy = new FixDiscountPolicy();위 처럼 선언을 하게되면, FixDiscountPolicy 클래스를 구현체로 사용한다는 것을 OrderServiceImpl이 알고 있는 것이다.
사용 영역의 클라이언트 코드
- 클라이언트가 사용하는 영역이다. 그렇기 때문에 Service layer는 전부 사용 영역이라고 할 수 있다. 주문, 회원가입, 조회 등의 행위 클라이언트가 전부 사용하는 것들이기 때문에 사용 영역이다라고 이해해도 좋다. 자세한 내용은 뒤에서 나온다.
지금까지 단순히 DiscountPolicy에만 의존한다고 생각했다.
하지만 사실은 주문 서비스 구현체인 OrderServiceImpl이 DiscountPolicy 인터페이스 뿐만 아니라 FixDiscountPolicy인 구현체에도 함께 의존하고 있었다. 고로 DIP 위반!!
OrderServiceImpl이 DIP를 위배하며 구현체인 FixDiscountPolicy를 의존하다보니 변경된 정책으로 수정할 때 의존하는 구현체도 변경해야해서 사용 영역 코드가 수정될 수 밖에 없다.(OCP위반)
지금까지 기존 코드가 왜 OCP, DIP를 위반하고 있었는지 할인 정책을 변경해보며 학습했다. 나의 결론은 DIP를 위반하지 않으면 즉, 구현체가 다른 구현체를 의존하지 않고 인터페이스에만 의존하게 코드를 작성하면 OCP 또한 지킬 수 있다는 것이다. 다음은 어떻게 코드를 작성해야 OCP, DIP를 위반하지 않을 수 있는지 김영한님 강의를 토대로 정리해보자!
!!김영한 강사님 강의