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

이 글은 강의 : 김영한님의 - "스프링 핵심원리 - 기본편"을 듣고 정리한 내용입니다. 😁😁

AppConfig 리팩토링

이전까지 AppConfig를 만들어서 관심사를 분리해서 본인들의 역할의 수행에만 집중할 수 있는 코드를 완성했다.
하지만, 다시 보면 AppConfig가 중복이 있고 역할에 따른 구현이 잘 안보이는 문제가 있다.

실제 원했던 그림은 이거였다. 역할(인터페이스)이 있고 구현 객체들이 어떤 것인지 명확하게 보이는 그림.

리팩토링 전

public class AppConfig {
    // 생성자 주입
    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
    }
    // 생성자 주입
    public OrderService orderService() {
        return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
    }
}

리팩토링을 하기 전의 AppConfig 의 모습. 중복으로 MemoryMemberRepository를 만드는 것도 있고, 역할에서 어떤 구현을 사용하는 지도 명확하게 보이지 않는다.

리팩토링 후

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

    // MemberRepository 역할
    private MemberRepository memberRepository() {
        return new MemoryMemberRepository();    // 메모리 회원 저장소로
    }

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

    // DiscountPolicy 역할
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();     // 고정 할인 정책으로
    }
}

역할과 구현을 명확하게 파악할 수 있도록 변경. 이제 MemberRepository의 구현체를 변경하고 싶다면 memberRepository()에서 리턴해주는 구현체만 변경해주면 전체가 동일하게 변경이 될 것이다.
또한 DisCountPolicy 역할에 따른 구현 역시 잘 보인다.

• FixDiscountPolicy를 다른 구현체로 변경할 때 DiscountPolicy 역할을 하는 메서드 한 부분만 변경하면 된다.

즉 메서드명을 보는 순간 역할(인터페이스)가 다 드러나잖아!

이렇게 리팩토링 후에 보니 애플리케이션의 구성이 어떻게 되는지 알아볼 수 있게 되었다!!!