본 게시글은 김영한님의 스프링 핵심 원리 기본편을 정리한 글입니다.
이전 시간 관심사를 분리하기 위하여서 기획자의 역할인 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 {
public MemberService memberService(){
return new MemberServiceImpl(memberRepository());
}
public MemberRepository memberRepository(){
return new MemoryMemberRepository();
}
public OrderService orderService(){
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
public DiscountPolicy discountPolicy(){
return new FixDiscountPolicy();
return new RateDiscountPolicy();
}
}
이게 위 코드와 밑에 코드를 보게 되면은 어찌보면 코드의 길이 상으로는 리팩토링 후의 코드가 더 길어진다는 것을 알 수 있지만 오히려 이제 중복이 더 사라지고 역할을 명확히 구분할 수 있다는 점에 있어서 더 보기 좋아졌다는 측면이 있다.
이게 지금은 코드가 생각보다 짧고 역할의 종류도 많지 않아서 티가 그렇게 안 날수도 있지만 이게 코드의 길이가 어마어마하게 증가를하게 된다면 밑의 방식처럼 memberRepository나 DiscountPolicy와 같이 따로 구분하여 만들어주는 것이 역할이 어떻게 되어있는지 더 명확하게 구분할 수 있다는 장점이 있었다.