Spring 핵심 원리 #3- 새로운 할인 정책/AppConfig 적용

#새로운 할인 정책의 개발

: 기획자가 이전의 고정 할인 정책에서 정률 할인 정책으로 바꾸고 싶다고 한다. 

-> 우리는 이전에 유연한 설계가 가능하도록 객체지향 설계 원칙을 준수하여 개발을 진행하였다.

: 인터페이스를 만들어 구현체 클래스에 각각의 역할을 따로 맡기고, 이후에 원하는대로 객체를 조합하여 사용할 수 있다.

 

Q) 실제로 이전의 설계가 객체지향 설계 원칙을 잘 준수했는가? 확인해보자

 

- 주문한 금액의 %를 할인해주는 새로운 정률 할인 정책을 추가하자.

-> DiscountPolicy를 상속받는 RateDiscountPolicy를 만들어 원하는 대로의 할인 정책을 실행할 수 있다.

 

 

#새로운 할인 정책 적용과 문제점

-> 그렇지만 이전의 코드는 객체지향원칙을 완벽히 준수하고 있지는 않다.

- 문제점이 무엇일까?

 1. 역할과 구현을 충실하게 분리했는가? => O

 2. 다형성을 활용하고, 인터페이스와 구현 객체를 분리했다. =>O

 3. OCP, DIP와 같은 객체지향 설계 원칙을 충실히 준수했는가?

   => 그렇게 보이지만 사실은 아니다.

 

1) 위의 할인 정책을 살펴보면 추상뿐만 아니라 구현체에도 의존하고 있다.

   - 추상(인터페이스) 의존 : DiscountPolicy

   - 구체(구현) 클래스 : FixDiscountPolicy, RateDiscountPolicy 

 => DIP 법칙을 위반하고 있다.

 

2) 지금 코드는 할인정책을 변경하려면 클라이언트 코드인 OrderServiceImpl 코드를 매번 변경해야 한다

 => 이는 클래스를 변경하지 않고 확장할 수 있다는 OCP 법칙을 위반한다.

 

지금까지는 우리가 DiscountPolicy 추상에 의존한다고 생각했다.

그렇지만 우리는 매번 추상과 구현체에 모두 의존하고 있었다.

따라서 할인 정책을 바꾸는 순간 OrderServiceImpl 코드도 변경해야 한다. => OCP 법칙을 위반함

 

- 이 문제를 해결하기 위해선 어떻게 해야 하는가?

 : DIP, OCP를 한꺼번에 해결하기 위해서 인터페이스에만 의존하도록 의존관계를 변경하면 된다.

=> 이런 식으로 생성자를 만들어 놓고, 인터페이스에만 의존하도록 한다.

: 그렇지만 이렇게 실행시에는 실체가 없는 인터페이스에 의존하므로 NullPointerException 이 터진다.

-> 이를 해결하기 위해 어디선가 DiscountPolicy, MemberRepository의 구현 객체를 생성하여 주입시켜줘야 한다.

 

 

 

#관심사의 분리

- 애플리케이션을 하나의 공연이라고 생각해보자.

-> 각각의 인터페이스를 배역이라고 생각하고, 구현체를 배우라고 생각할때 이전의 케이스에서는 배우가 다른 배역을 맡는 배우를 직접 초빙해야 하는 것(구현체에 직접 의존)과 같다. 즉 배우가 다양한 책임을 갖고 있다.

 

- 배우는 본인의 역할을 수행하는 것에만 집중해야 하며, 어떤 상대 주인공이 선택되더라도 똑같이 연기를 해야 한다.

- 따라서 공연을 구성하고, 배우를 섭외하고, 역할을 지정하는 별도의 기획자가 나설 차례이다.

- 공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실히 분리하자.

 

 

#AppConfig의 등장

: 애플리케이션 전체 동작방식을 구성하기 위해 구현 객체를 생성하고, 연결하는 책임을 갖는 별도의 설정 클래스를 만들자.

- AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다

: MemberServiceImpl, OrderServiceImpl, MemoryMemberRepostiory, FixDiscountPolicy

 

- 또한 AppConfig에서 객체 인스턴스의 참조를 생성자를 통해서 주입(연결)해준다.

 1) MemberServiceImpl -> MemoryMemberRepository 

 2) OrderService -> MemoryMemberRepository, FixDiscountPolicy

 

-> 실제로 OrderServiceImpl 클래스를 살펴보면 추상만 의존하고 있음을 확인할 수 있다

: 이 클래스 입장에서는 생성자를 통해 어떤 구현 객체가 들어올지는 알 수 없다. 어떤 구현 객체가 주입될지는 오직 외부(AppConfig)에 의해 결정된다.

: MemberServiceImpl은 의존관계에 대한 고민은 외부(AppConfig)에 맡기고 실행에만 집중하면 된다.

 

- 객체의 생성과 연결은 철저히 AppConfig 부분이 담당하고 있다.

- DIP를 준수함 : MemberServiceImpl은 MemberRepository 추상에만 의존하고 있는 것을 확인할 수 있다.

- 관심사의 분리 : 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되고 있다.

 

- AppConfig 객체는 MemoryMemberRepository 객체를 생성하고, 그 참조값을 memberServiceImpl 객체를 생성한 이후에 생성자로 주입해준다.

- 클라이언트인 memberServiceImpl 입장에서 보면 의존 관계를 마치 외부에서 주입해주는것 같다고 하여 이를

  : Dependency Injection, 의존성 주입/의존관계 주입이라고 한다.

 

 

-이를 실제로 어떻게 활용할 수 있는지 확인해보자.

=> 코드를 확인해보면 철저히 구현체 클래스를 선택하는 등의 책임은 AppConfig에 일임하고 있다.

: AppConfig가 애플리케이션이 어떻게 동작해야 하는 전체 구성을 책임지고, OrderServiceImpl은 어떤 구현체가 선택될지 전혀 알지 못하고 기능을 실행하는 책임만 지면 된다.

 

#정리

1) AppConfig를 통해 구현체 클래스를 선택하고, 애플리케이션이 어떻게 동작할지 전체 구성을 책임지게 된다.

2) 추후 어플리케이션 실행 코드에서 AppConfig를 통해 실제 MemberService/OrderService 객체를 생성한다.

3) OrderService/MemberSerivce 역시 구현체(OrderServiceImpl/MemberServiceImpl)에 의존하지 않고,어떤 Impl 구현체가 할당될지 모르며, 멤버 변수를 결정하는 생성자에 어떤 구현체가 주입될지 전혀 알지 못한다.

4) 각각의 클래스는 할당된 기능만 수행하면 되고, 어떤 할인 정책이나 DB 정책을 사용할지는 전부 AppConfig에 일임하면 된다.

 

 

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