정리

새로운 할인 정책 개발

다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없었다.

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

새로운 정률 할인을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체도 함께 변경해야 했다. OCP를 위반하는 것이다.

주문 서비스 클라이언트가 인터페이스인 DiscountPolicy뿐 아니라, FixDiscountPolicy도 함께 의존하므로 추상적인 것에 의존해야 하는 DIP도 위반한다.

관심사의 분리

애플리케이션을 하나의 공연으로 생각한다. 기존에는 클라이언트가 의존하는 서버의 구현 객체를 직접 생성하고 실행했다. 배우가 공연도 하면서 상대 배우도 초빙하는 다양한 책임을 가진 것이다.

공연을 구성하고 배우를 섭외하는 별도의 공연 기획자가 필요하다. AppConfig를 이용해 애플리케이션의 전체 동작 방식을 구성한다. 어떤 구현 객체를 생성하고 연결할지에 대한 책임을 가진다.

이제 클라이언트 객체는 자신의 역할을 실행하는 것만 집중한다. 권한이 줄어들고 책임이 명확해졌다.

AppConfig 리팩터링

역할과 구현을 명확히 분리하는 방식을 구성 정보에도 적용한다. 서비스는 어떤 서비스 구현체를, 저장소는 어떤 저장소 구현체를 쓰는지 메서드로 따로 분리했고 중복도 제거되었다.

새로운 구조와 할인 정책 적용

AppConfig의 등장으로 애플리케이션이 사용 영역과 구성 영역으로 분리되었다. 이제 새로운 할인 정책으로 바뀌어도 AppConfig가 있는 구성 영역만 변경하면 된다. 클라이언트 코드인 주문 서비스 코드는 전혀 변경할 필요가 없다.

좋은 객체 지향 설계의 5가지 원칙 적용

이 예제에서는 총 세 가지 원칙을 적용했다.

SRP 단일 책임 원칙

• 한 클래스는 하나의 책임만 가져야 한다.

원래 클라이언트 객체가 직접 구현 객체를 생성, 연결, 실행하는 다양한 책임을 가지고 있었다. SRP 원칙을 따르면서 관심사를 분리한 뒤 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당하게 되었다. 클라이언트 객체는 이제 실행하는 책임만 갖게 된다.

DIP 의존 관계 역전 원칙

• 추상화에 의존해야지 구체화에 의존하면 안된다.

의존성 주입은 이 원칙을 따르는 방법 중 하나다.

새로운 할인 정책을 개발하고 적용하려면 클라이언트 코드도 함께 변경해야 했다. OrderServiceImpl이 추상화된 인터페이스 DiscountPolicy에 의존하는 동시에 구체화된 구현 클래스 FixDiscountPolicy에도 의존했기 때문이다.

클라이언트 코드가 DiscountPolicy 인터페이스에만 의존하도록 변경해도 인터페이스만으로는 아무것도 실행할 수 없다.

AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 대신 생성해서 의존 관계를 주입하면 DIP 원칙을 따르면서 해당 문제도 해결하게 된다.

OCP

• 소프트웨어는 확장에는 열려있고 변경에는 닫혀있어야 한다.

애플리케이션을 사용 영역과 구성 영역으로 나눴다. AppConfig에서만 의존 관계를 변경하고 클라이언트 코드는 변경하지 않아도 되므로 소프트웨어 요소를 새로 확장해도 사용 영역의 변경은 닫혀있다고 할 수 있다.