Spring 핵심 원리 #4- AppConfig 리팩토링/총정리

# 기존의 AppConfig 코드

- 기존 코드를 살펴보면 MemoryMemberRepository 객체의 중복 생성이 존재하며, 각 클래스의 역할이 잘 안보인다.

: 생성자가 인터페이스에 의존하므로 각 구현체 정보만 확인할 수 있기 때문이다.

 

 

#AppConfig 리팩토링

=>AppConfig의 중복이 제거되었고, 구현체들의 역할이 훨씬 잘 보인다.

 

 

# AppConfig의 역할 총정리

: AppConfig가 등장함으로써 애플리케이션이 크게 사용 영역과 객체를 생성하고 구현체를 할당하여 구성하는 구성(Configuration) 영역으로 나뉘었다.

 

-> 만약 할인 정책을 RateDiscountPolicy로 변경해도 사용영역은 전혀 영향을 받지 않고 구성 영역만 바뀌게 된다.

: 구성 영역은 당연히 변경되는 것으로, 구성 역할을 담당하는 AppConfig를 Application의 기획자라고 생각하자. 기획자는 공연 참여자인 구현 객체를 모두 아는것은 당연한 것.

 

 

#흐름 정리

: 포스팅 #3~#4까지의 흐름을 모두 정리해보자

1. 새로운 할인 정책 개발

-> 다형성 덕분에 새로운 정률 할인 정책 클래스를 구현하는 것 자체는 문제가 없다.

 

2. 새로운 할인 정책 적용시 발생하는 문제점

-> 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 OrderServiceImpl 코드에서 주문 서비스 구현체도 변경해야 한다.

: 이는 주문 서비스 클라이언트가 인터페이스뿐만 아니라 구현체도 의존하므로 DIP를 위반한다.

 

3. 관심사의 분리

-  현재는 클래스가 여러가지 책임을 안고 있으므로 객체를 생성하고, 구현체를 연결하는 등의 역할을 하는 별도의 기획자를 두자.

-> 공연 기획자인 AppConfig가 여기서 등장한다. AppConfig는 애플리케이션의 전체 동작 방식을 구성하기 위해 구현 객체를 생성하고, 이를 OrderServiceImpl 생성자에 주입하여 의존성을 주입하게 된다. 

: 이를 Dependency Injection이라고 한다. 이를 통해 클라이언트 객체는 본인의 기능만 실행하므로 책임이 줄어든다.

 

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

- 정액 할인에서 정률 할인으로 정책을 변경하려 한다.

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

- 할인 정책을 변경해도 AppConfig가 있는 구성 영역만 변경하면 되고, 사용 영역은 변경할 필요가 없다.

 

 

#위 포스팅은 인프런 김영한 팀장님의 스프링 핵심 기본편을 수강한 내용을 정리하였습니다.