전체 흐름 정리

전체 흐름 정리

이번 시간에는 이제까지의 전체 흐름을 쭉 정리를 해드릴게요.

먼저 처음에 우리가 했던 게 새로운 할인 정책을 개발했죠. 그랬더니 다형성 덕분에 새로운 정액 할인 정책에서 정률 할인 정책 인터페이스를 받아서, 추가 클래스를 구현하는 것 까지는 아무 문제가 없었어요. 테스트까지 다 마쳤었죠.

그런데 이 새로운 할인 정책을 실제 애플리케이션에 반영을 하려다 보니까 무슨 문제가 생겼냐면, 새로 개발한 정률 할인 정책을 적용을 하려고 하는데 클라이언트 코드인 주문 서비스 구현체도 함께 변경을 해야되는 문제가 생겼었습니다. 이게 OCP를 위반하게 되는 거죠.

왜냐하면 주문 서비스 클라이언트가 인터페이스인 DiscountPolicy뿐만 아니라 구체 클래스인 FixDiscountPolicy도 함께 의존하고 있었기 때문에 그래요. 이거는 DIP를 위반하는 거죠. 추상화에만 의존해야 되는데 구체적인 것까지 의존을 하고 있었던 거죠.

그래서 생각을 해보니까, 클라이언트 코드인 주문 서비스 구현체가 너무 많은 역할을 하고 있었던 거예요. 주문과 관련된 기능(createOrder)도 개발해야 되고, FixDiscountPolicy 객체도 생성을 하고 이렇게 했어야 했던 거죠.

자 그래서 관심사를 분리를 했습니다.

애플리케이션을 하나의 공연이라고 생각하면, 기존에는 클라이언트가 의존하는 서버에 대한 어떤 구현 객체를 직접 생성을 하고 실행도 한 것처럼 너무 다양한 책임을 가지고 있었던 거죠.

그래서 공연을 구성을 하고 담당 배우를 섭외하고 지정하는 책임을 담당하는 별도의 공연 기획자가 나와야 되는 시점이었던 거에요. 단일 책임 원칙(SRP)를 봐도 하나가 너무 다양한 책임을 가지면 좋지 않거든요. 그래서 책임을 분리하는 겁니다.

그래서 공연 기획자인, 애플리케이션의 구성을 담당하는 AppConfig가 등장을 했습니다.

이 AppConfig는 애플리케이션의 전체 동작 방식을 configuration, 그러니까 구성 또는 설정을 하기 위해서 구현 객체를 생성하고 연결하는 책임을 AppConfig가 다 지게 됩니다. 그래서 기존의 클라이언트 객체들은 자신의 역할을 실행하는 것만 집중하면 되고, 자기가 사용하는 객체를 생산하는 거에 대한 거는 하지 않아도 되는 거에요. 결과적으로 권한이 줄어든 거지만, 반대로 얘기하면 클라이언트 객체의 책임이 더 명확해진 거죠.

---

그리고나서, 이제 AppConfig를 한번 리팩터링을 했죠.

객체지향 설계에서 중요한 것은 역할과 구현을 명확하게 분리해야 된다고 했었죠. 그렇게 했는데 그 AppConfig 구성 정보에서도 역할과 구현을 명확하게 분리를 했습니다. 그리고 역할이 굉장히 잘 드러나게 리팩터링 했고요. 또 new로 객체생성하는 부분의 중복을 제거해줬습니다.

---

자 그런 다음에 구조를 바꾸고 나서 이 새로운 구조의 할인 정책을 적용을 해봤죠.

무조건 1000원을 할인하던 정액 할인 정책을 10% 할인하는 정률 할인 정책으로 변경을 했어요.

그렇게 했더니, AppConfig의 등장으로 인해서 애플리케이션이 사용하는 영역과 애플리케이션을 구성하는 영역으로 크게 분리가 되면서, 할인 정책을 변경을 하더라도 AppConfig가 있는 구성 영역만 변경하면 되고, 실제 애플리케이션 로직들이 다 있는 사용 영역은 전혀 변경할 필요가 없어진 거예요. 물론 제일 중요한 DiscountPolicy의 클라이언트 코드인 OrderService 구현 코드도 전혀 변경할 필요가 없어졌습니다.

이렇게 해서 DIP, OCP를 둘 다 지킬 수 있었던 거죠. 바로 이 AppConfig의 등장으로 이것이 가능하게 됐던 겁니다.

---

자 다음 시간에는 우리가 지금까지 적용했던 좋은 객체지향 설계 5가지 원칙들이 어떻게 반영이 됐는지 설명을 해드리겠습니다.