[Web] Spring 핵심 원리 6.5 - 중간 점검 (전체 흐름 정리)

서론

- 지금까지 과정의 흐름을 정리한다.

1. 비즈 니스 요구사항에 따른 프로젝트 설계 (FixDiscountPolicy)
2. 비즈 니스 요구사항의 변경에 따른 새로운 할인 정책 (RateDiscountPolicy) 개발 
3. 새로운 할인 정책 적용과 문제점
4. 관심사의 분리
5. AppConfig 리팩터링
6. 새로운 구조와 할인 정책 적용

 

---

 

1. 비즈니스 요구사항에 따른 프로젝트 설계 (FixDiscountPolicy)

• 비즈니스 요구사항에 따라 고정 할인 정책(FixDiscountPolicy)으로 할인하는 서비스를 설계하였다.
• 이때, 기능의 확장을 위해 다형성을 위해 인터페이스와 구현체를 분리하여 설계한다.

 

2. 비즈 니스 요구사항의 변경에 따른 새로운 할인 정책 (RateDiscountPolicy) 개발

• 다형성을 고려하여 인터페이스와 구현체를 분리하여 설계한 결과 기존의 FixDiscountPolicy를 그대로 두고 RateDiscountPolicy를 새로 만드는것은 아무 문제가 없었다.

 

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

• 새로 만든 RateDiscountPolicy를 적용하려는데, 클라이언트 코드인 OrderServiceImpl의 코드를 변경해야하는 일이 생겼다.
• 그 이유는 OrderServiceImpl이 DiscountPolicy 인터페이스 뿐만 아니라 FixDiscountPolicy도 함께 의존했기 때문이다.
• 이를 통해, 여태까지 작성한 코드가 DIP와 OCP를 위반한다는것을 알게되었다.
• 따라서 이를 해결하기위해 관심사를 분리할 필요를 느끼게 되었다.

 

4. 관심사의 분리

• 관심사를 분리 하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가진 별도의 클래스 AppConfig를 설계하였다.
• AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다.

 

5. AppConfig 리팩터링

• 중복되는 코드를 없애고, 역할과 구현이 한 눈에 들어오도록 AppConfig를 리팩토링 하였다.

 

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

• 기존의 할인 정책을 변경하기 위해 이제 클라이언트 코드를 건드릴 필요가 없어졌다.
• 할인 정책 뿐만아니라, 다른 구현체 또한 AppConfig의 코드만 변경하여 주입할 수 있다.

 

결론

SRP와 DIP, OCP를 준수하게 되었다. = 객체 지향의 관점에서 좋은 설계를 하였다

- SRP 단일 책임 원칙 : "한 클래스는 하나의 책임만 가져야 한다."

• 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당
• 클라이언트 객체는 실행하는 책임만 담당

- DIP 의존관계 역전 원칙 : "프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다."

• AppConfig를 통해 클라이언트 코드가 인터페이스와 구현체 둘다 의존하는 문제를 해결함

- OCP 개방/폐쇄의 원칙 : "소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다."

• 다형성을 사용하고 클라이언트가 DIP를 지킴
• 애플리케이션을 사용 영역과 구성 영역으로 나우었기 때문에 구현체를 추가하여 기능을 확장해도 사용영역의 변경에는 닫혀있다.