171일차(모험 80일차) - 새로운 구조와 할인 정책 적용

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

정액 할인 정책을 정률% 할인 정책으로 변경하기

FixDiscountPolicy ➡️ RateDiscountPolicy

 

AppConfig의 등장으로 애플리케이션이 크게 사용 영역과,

객체를 생성하고 구성(Configuration)하는 영역으로 분리

 

사용 영역과 구성 영역(* pdf 그림 보기!)

FixDiscountPolicy ➡️ RateDiscountPolicy 로 변경해도 구성 영역(AppConfig)만 영향을 받고,

사용 영역은 전혀 영향을 받지 않는다

 

 

AppConfig가 OrderServiceImpl과 FixDiscountPolicy를 생성했는데

할인 정책의 변경으로 AppConfig가 OrderServiceImpl과 RateDiscountPolicy를 생성한다.

 

 

 

AppConfig

public DiscountPolicy discountPolicy() {
    //return new FixDiscountPolicy();
    return new RateDiscountPolicy();
}

위 코드와 같이 AppConfig에서 할인 정책 역할을 담당하는 구현을

FixDiscountPolicy ➡️ RateDiscountPolicy 객체로 변경하면 된다.

 

이제 할인 정책을 변경해도, 애플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 된다.

클라이언트 코드인 OrderServiceImpl 를 포함해서 사용 영역의 어떤 코드도 변경할 필요가 없다.

 

 

 

맞게 적용이 되는지 확인해본다.

 

OrderApp

 

10,000원일 경우 1,000원 할인

 

20,000원일 경우 2,000원 할인

 

 

 

AppConfig에서 아래와 같이 변경한 후에 20,000원일 경우의 할인 금액을 비교해본다.

public DiscountPolicy discountPolicy() {
    return new FixDiscountPolicy();
    //return new RateDiscountPolicy();
}

 

FixDiscountPolicy로 설정했을 경우 1,000원 할인

 

 

 

 

OrderServiceImpl

중요한 건 사용영역에 있는 코드는 변경할 필요가 전혀 없다.

 

 

추상화에 의존 ➡️ DIP 만족

코드를 바꿨는데도 기존의 클라이언트 코드를 변경한게 없다. ➡️ OCP 만족

 

DIP와 OCP 모두 만족한다.

 

 

구성 영역은 당연히 변경된다.

구성 역할을 담당하는 AppConfig를 애플리케이션이라는 공연의 기획자로 생각한다.

공연 기획자는 공연 참여자인 구현 객체들을 모두 알아야 한다.

 

 

---

전체 흐름 정리 (중간정리)               

interface	구현체(구현 클래스)
DiscountPolicy	FixDiscountPolicy, RateDiscountPolicy
MemberRepository	MemoryMemberRepository
MemberService	MemberServiceImpl
OrderService	OrderServiceImpl

 

클라이언트 코드 OrderServiceImpl, memberServiceImpl

 

인터페이스와 구체 클래스 함께 의존 ➡️ DIP 위반 

 

 

자세한 내용은 pdf 참고하기!

- 새로운 할인 정책 개발

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

- 관심사의 분리

- AppConfig 리팩터링

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