[스프링 핵심 원리 - 기본편] 인프런 강의 정리(객체 지향 원리 적용 - AppConfig 리팩터링)

/* 이 글은 김영한님의 강의를 보고 정리하려고 작성한 글입니다.

   개인적인 공부를 위해 올리는 글이므로 중간 중간 코드는 생략되었습니다. */

 

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

 

 

 

 

 

AppConfig 리팩터링

 

 

1. 리팩터링 전

 

 

appConfig

 

public class AppConfig {

    public MemberService memberService() {

        return new MemberServiceImpl(new MemoryMemberRepository());

    }

    public OrderService orderService() {

        return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());

    }

}

 

◾ 현재 appConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 보이지 않음

◾ 역할을 드러내기 위해서 메소드를 추출해서 리팩토링 함

 

1. 추출할 부분을 블럭으로 지정한 후 Ctrl + Alt + M

2. 이름을 추천해주면 원하는 이름 선택하고 엔터

3. 이름을 직접 지정하고 싶다면 이름 추천 단계에서 Alt + Shift + O ➔ Ctrl + Alt + M 누르면 이 화면이 뜸

4. Replace 선택(중복된 부분 알아서 고쳐줌)

 

 

 

2. 리팩터링 후

 

appConfig

 

public class AppConfig {

    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

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

}

 

◾ new MemoryMemberRepository() 부분의 중복이 제거되었다. 이제 Repository를 변경해야 한다면 한 부분만 수정하면 된다.

◾ appConfig의 역할이 한 눈에 들어온다.

 

💡 궁금증 1

: 직접 의존성을 생성하는 것(new로 객체 생성)과 메소드를 통해 의존성을 생성하는것의 차이

 

◾ 직접 의존성을 생성하는 경우 :

- 만일 Repository를 DbMemberRepository로 변경해야 한다면 `new MemoryMemberRepository()` 로 직접 생성한 코드를 모두 찾아 변경해야 하며, 나중에 범위가 커진다면 다른 코드에 영향을 미칠 수 있다.

- 직접 의존성을 생성하면 클래스가 해당 의존성에 강하게 결합되어 추상화 수준이 낮아지고 코드 변경과 유지보수가 어려워 진다.

 

◾ 메소드를 통해 의존성을 생성하는 경우 : 

- 만일 Repository를 DbMemberRepository로 변경해야 한다면 `memberRepository()`의 메소드만 수정하면 된다. 코드의 변경 범위를 최소화 할 수 있다.

- 메소드를 통해 의존성을 주입하면 MemberServiceImpl 클래스는 `memberRepository()`가 반환하는 `MemberRepository` 인터페이스에 의존하므로 추상화를 통해 다양한 구현을 할 수 있다.

 

➔ 결론 : 의존성 분리할 수 있고 단일 책임 원칙을 준수하며 유연성과 확장성에 용이하다.