[김영한 스프링] 07. AppConfig 리팩터링, 새로운 구조와 할인 정책 적용

현재 AppConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 안 보인다.

 

기대하는 그림

 

MemberRepository의 역할이 보여야 하는데 전혀 보이지 않음. 그래서 리팩터링

 

MemberRepository 생성 됨

 

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {
   
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    
    private MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }
    
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

메서드 명을 보는 순간 역할을 다 알 수 있음

나의 애플리케이션에서는 MemberService를 MemberServiceImpl로 쓸거야

나의 애플리케이션에서는 MemberRepository를 MemoryMemberRepository로 쓸거야

OrderService는 나의 애플리케이션에서 결정한 memberRepository를 가져오고 discountPolicy를 가져올거야

 

정리

• 'new MemoryMemberRepository()' 이 부분이 중복 제거되었다. 이제 MemoryMemberRepository를 다른 구현체로 변경할 때 한 부분만 변경하면 된다.
• 역할과 구현 클래스가 한눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다.

 

연기하는 배우들의 역할과 공연을 기획하고 담당자를 섭외하는 역할이 완전히 나누어 지게 됨

 

 

• FixDiscountPolicy를 RateDiscountPolicy로 변경
• 할인 정책을 변경해도, 애플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 된다. 클라이언트 코드인 OrderServiceImpl를 포함해서 사용 영역의 어떤 코드도 변경할 필요가 없다.
• 구성 영역은 당연히 변경된다. 구성 역할을 담당하는 AppConfig를 애플리케이션이라는 공연의 기획자로 생각하자. 공연 기획자는 공연 참여자인 구현 객체들을 모두 알아야 한다.

 

 

출처 : https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8

스프링 핵심 원리 - 기본편 - 인프런 | 강의