5. 객체 지향 원리 적용 - AppConfig 리팩터링

목표

1.  예제 프로젝트에 객체 지향 원리를 적용한다.
2. 이전 시간에 만든 AppConfig를 리팩터링하고 공부한 내용을 정리한다.

'객체 지향 원리 적용' 목차

1. 새로운 할인 정책 개발

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

3. 관심사의 분리

4. AppConfig 리팩터링 (이번 포스팅)

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

6. 전체 흐름 정리 

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

8. IoC, DI, 그리고 컨테이너 

9. 스프링으로 전환하기

---

4. AppConfig 리팩터링

현재 AppConfig의 중복을 제거하자. 역할에 따른 구현을 분명하게 만들자. 

아래는 목표로 하는 도메인 협력관계다. AppConfig 에서 이 그림의 모든 요소를 드러나도록 바꾸자. 

리팩토링 전 AppConfig 

리팩토링 후 AppConfig 코드

메서드 명을 보면 역할 마다의 구현이 모두 드러나있다. 애플리케이션의 구성이 한 눈에 들어온다. 

AppConfig를 도입해서 애플리케이션이 사용 영역과 객체를 생성하고 구성하는 영역으로 분리됬다. 

 

---

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

기획자의 요구사항대로 정률% 할인 정책으로 변경하자. 

FixDiscountPolicy를 RateDiscountPolicy로 구현체가 변경되어야 하는데. 어디를 바꿔야 할까? 

 

클라이언트를 건드리지 않고 AppConfig만 수정하면 된다. 

DiscountPolicy 역할(인터페이스)의 구현체를 RateDiscountPolicy로 바꾸면 끝이다!

공연기획자 AppConfig 가 모든 역할과 구현을 선택한다. 

사용 영역의 변경이 필요없다!

---

6. 전체 흐름 정리 

지금까지 배운 것을 정리해보자. 

 

1. 새로운 할인 정책 개발

할인 정책 인터페이스와 할인 정책 구현체를 분리해뒀다.

역할과 구현이 분리되어 있으니 새로운 정률 할인 정책 코드를 추가 개발하는 것에 문제가 없다.

 

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

새로 개발한 정률 할인 정책을 적용하려고 하니까 클라이언트 코드를 변경해야 하는 문제를 발견했다. 

주문 서비스가 할인 정책 인터페이스 DiscountPolicy 뿐만 아니라 구현체 FixDiscountPolicy도 둘다 의존하고 있었기 때문이다. 

-> DIP 위반! 추상에만 의존해야 하는데. 구현체에도 의존하고 있는 문제.

 

3. 관심사의 분리

기존에는 구현체 다른 구현체를 직접 선택하는 다양한 책임을 가지고 있었다. 

구현체는 기능 구현에만 집중하게 두자.

역할 마다의 구현체를 지정하는 책임을 맡을 공연 기획자가 필요해졌다!

공연 기획자 AppConfig를 만들어서 전체 동작 방식을 구성하도록 했다. 

AppConfig는 구현 객체를 생성하고 연결하는 책임을 가진다. 

클라이언트는 기능 구현이라는 책임이 명확해졌다. 

 

4. AppConfig 리팩터링

중복을 제거했다. 구성 정보에서 역할과 구현을 명확하게 분리했다. 

 

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

새로 개발한 정률 할인 정책을 적용했다. 구성영역인 AppConfig만 수정하면 됬고 사용영역은 변경할 필요가 없었다. 

---

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

예제 프로젝트에서 SOLID원칙이 적용된 것을 확인해보자. 여기서 SRP, DIP, OCP가 적용되었다. 

 

SRP 단일 책임 원칙 

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

• 클라이언트 객체는 객체 생성, 연결, 실행하는 다양한 책임을 가지고 있었다. 
• 구현 객체를 생성하고 연결하는 책임을 AppConfig가 담당하도록 넘겼다. 클라이언트 객체는 기능 실행만 맡게 됬다. 

DIP 의존관계 역전 원칙  

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

• 새로운 할인 정책을 개발하고 적용하려고 하니 클라이언트 코드를 변경해야 하는 문제를 발견했다. 
• 왜냐하면 클라이언트 코드 OrderServiceImpl이 DiscountPolicy 인터페이스에만 의존하는 것 같았지만, FixDiscountPolicy 구현체에도 의존하고 있었기 때문이다. 
• 클라이언트 코드 OrderServiceImpl이 DiscountPolicy 인터페이스에만 의존하도록 변경했다. 
• AppConfig가 FixDiscountPolicy 인스턴스 생성하여 의존관계를 클라이언트 코드에 주입했다. 

OCP 개방 폐쇄 원칙

"소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다."

• 구성영역인 AppConfig가 의존관계를 결정한다. 
• 따라서 소프트웨어 요소를 새롭게 확장해도 사용영역(클라이언트 코드)을 변경하지 않아도 된다. 

---

다음 강의에서는 스프링의 IoC, DI 그리고 컨테이너를 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편