AppConfig 리팩터링 (+ 역할 요약)

이전 학습 내용 :

AppConfig를 따로 두어서 생성&주입의 책임을 서비스 클래스의 외부(AppConfig)로 빼주었다.

의존관계 주입(DI)를 구현한 것이다. 

 

그런데 단순히 구현해본 AppConfig는 리팩터링이 필요하다.

그 내용을 보쟛

(단축키 : Ctrl + Alt + M)

 

 

---

∨ 이전

 

- 중복 제거가 필요

: 매개변수를 보자. new MemoryMemberRepository()가 중복으로 있다. 

: 중복 제거가 필요하다 => 다른 구현체로 변경할 경우 힘들어짐

: 그 new하는 책임을 메서드 하나로 따로 빼주자. 

 

- 애플리케이션의 구조가 보이지 않음

: 역할&구현이 분리되지 않았다.

: 예를들면 memberService 역할 속에 new MemoryMemberRepository()라는 구현체 생성이 포함되었다.

이럴 경우 "역할 따로, 구현 따로"를 지키지 못하고,

AppConfig로 구조를 한눈에 파악할 수 없다.

 

public class AppConfig {

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

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

 

 

 

∨ 이후 :

 

[ 애플리케이션 전체 구성을 한눈에 볼 수 있다 ]

메서드명만 봐도 역할&구현 클래스가 뭔지 단번에 알 수 있다. 

이전에는 memberService()에서 구현체를 정했지만 (new XXXMemberRepository() 부분)

이제는 어떤 구현체를 사용할지에 대한 메서드인 memberRepository()를 따로 빼주었다!

=> 그러면 어떤 구현체를 사용하는지도 잘 보인다.

discountPolicy() 만 보고도.. 아 할인정책은 FixDiscountPolicy를 쓰는구나~ 를 알 수 있다.

 

[ 중복 제거의 이점 ]

- 혹시 저장소를 DB로 변경하고 싶으면 직접관련되는 그 메서드만 슉 찾아 건들면 된다.

지금은 memberRepository()에서 return new MemoryMemberRepository()하고 있지만, 

저장소 변경을 원하면 그 메서드 내부에서만 구현체를 DbMemberRepository()로 수정해주면 된다는 것이다.

=> 중복제거를 했으므로 여러 수정이 불필요해짐!!

할인정책 변경도 같은 과정이다.

 

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 RateDiscountPolicy();
    }
}

 

리팩터링 끝!

 

.

.

 

[ AppConfig 관련 요약 ]

 

+ 이렇게 잘 만든 AppConfig를 두었기 때문에,

애플리케이션을 '사용 영역'과 '구성 영역'으로 나눌 수 있다.

AppConfig를 쓰기 이전에는 구현체 변경시 사용영역(클라이언트 코드)을 건드려야 했다면, 

이제 구현체에 변경사항이 있으면 구성역할을 담당하는 AppConfig 코드만 살짝 변경해주면 된다. 

 

+ 구성영역은 당연히 변경대상인 영역이다.

+ 구성영역을 담당하는 AppConfig에는 구현객체들을 모두 명시해야 한다.

 

+ (중요한 결말) : AppConfig를 두었기 때문에 OCP, DIP원칙을 지킬 수 있게 되었다!

 

* AppConfig를 만들어본 것과 같이,

프로그램의 제어흐름을 직접 제어하지 않고 외부에서 제어하는 것을 IOC(제어의 역전)이라고 한다. 

* AppConfig는 의존관계역전을 해준다.

 

 

 

---

예전에 실전 자바 소프트웨어 개발 공부할 때 이 리팩터링 개념이 나왔었다.

그때 한번 보고 지금 다시 보니까 AppConfig내에서 중복제거하는 부분이 반가웠다..

하이~

 

그러면서도.. 멈췄다가 너무 오랜만에 공부하는 느낌이 확 났다.

여름방학에는 멈추지 않고 쭉 하고.. 학기중에도 멈추지 말고.. 그러자..

흐름 잃지 말아야 잘 살아가겠쥐