[스프링 핵심 원리 - 기본편] 스프링 핵심 원리 이해2 - 객체 지향 원리 적용(2)

AppConfig 리팩터링

• AppConfig를 보면 중복되는 코드들이 있고, 역할에 따른 구현이 잘 안보인다.
  
  

  

 

 

 

• 리팩터링 전

public class AppConfig {

	public MemberService memberService() {
		return new MemberServiceImpl(new MemoryMemberRepository());
	}
	
	public OrderService orderService() {
		return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
	}

}

 

• 리팩터링 후

public class AppConfig {
    //memberService 역할, 생성자 주입
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    //orderService 역할, 생성자 주입
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    //memberRepository 역할
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

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

• new MemoryMemberRepository() 이 부분이 중복 제거되었다. 이제 MemoryMemberRepository 를 다른 구현체로 변경할 때 한 부분만 변경하면 된다.

• AppConfig 를 보면 역할과 구현 클래스가 한눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다.

 

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

• 정액 할인 정책을 정률 할인 정책으로 변경

• AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다.

  

• 할인 정책을 변경한다면 구조는 다음과 같다.

  

• 할인 정책 변경 구성 코드 

public class AppConfig { 

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

}

• AppConfig 에서 할인 정책 역할을 담당하는 구현을 변경해도, 애플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 된다.
  • 클라이언트 코드인 OrderServiceImpl 를 포함해서 사용 영역의 어떤 코드도 변경할 필요가 없다.

• 구성 영역은 당연히 변경된다. 구성 역할을 담당하는 AppConfig를 애플리케이션이라는 공연의 기획자로 생각하자. 공연 기획자는 공연 참여자인 구현 객체들을 모두 알아야 한다.

---

[참고자료]

스프링 핵심 원리 - 기본편, 김영한