[Inflearn] 새로운 할인 정책 적용의 문제점 & 해결방안(관심사 분리) (SRP 만족)

앞에서 OrderServiceImpl 코드를 고쳐야 한다고 했었다.

 

• 역할과 구현을 충실하게 분리했는가? (YES)
• 다형성도 활용하고, 인터페이스와 구현 객체를 분리했는가? (YES)
• OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했는가? (NO)

문제점

 

* DIP "프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다"
인터페이스뿐 아니라 구현 클래스에도 의존하고 있다.
- 추상(인터페이스) 의존: DiscountPolicy
- 구체(구현) 클래스 의존: FixDiscountPolicy, RateDiscountPolicy

* OCP "변경하지 않고 확장이 가능하다"
지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다.
(OrderServiceImpl 코드를 바꿔야 했다.)

 

 

쉽게 클래스 다이어그램으로 표현하자면 다음과 같다.

 

원래 OCP/DIP를 지키려면 다음과 같은 클래스 다이어그램 형태가 기대된다.

 

 

Good

 

OrderServiceImpl() 이 DiscountPolicy(인터페이스)와 Fix/RateDiscountPolicy(구현 클래스) 모두에 의존

=> DIP 위반 

Bad(DIP 위반)

 

FixDiscountPolicy에서 RateDiscountPolicy로 바꾸려면  OrderServiceImpl의 소스도 함께 변경해야 함

=> OCP 위반

Bad(OCP 위반)

 

어떻게 문제를 해결할 수 있을까?

 

Sol 1

 

다음과 같이 인터페이스에만 의존하도록 코드를 변경할 수 있다. => DIP 위반 해결

 

하지만 실제로 구현해보면 NPE(null pointer exception)이 발생한다.

구현체가 없기 때문에 24번째 줄의 코드를 실행할 수 없기 때문이다.

 

이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해주어야 한다.

그 누군가를 추가하는 것이 Sol 2이다.

 

Sol 2

 

관심사를 분리하여 책임을 확실히 분리하는 방법이다.

 

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

그리고 각각의 인터페이스를 배역이라고 생각해보자.

 

로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할지, 줄리엣 역할을 누가 할지는 배우들이 정하는 게 아니다.

이전 코드는 마치 로미오 역할(인터페이스)을 하는 레오나르도 디카프리오 배우(구현체)가

줄리엣 역할(인터페이스)을 하는 여자 주인공(구현체)을 직접 초빙하는 것과 같다.

디카프리오는 공연도 해야 하고 동시에 여자 주인공도 공연에 직접 초빙해야 하는 다양한 책임을 가지고 있다.

 

이 책임을 분리하자는 것이다.

• 배우는 본인의 역할인 배역을 수행하는 것이만 집중해야 한다.
• 디카프리오는 어떤 여자 주인공이 선택되더라도 똑같이 공연을 할 수 있어야 한다.
• 공연을 구성하고, 담당 배우롤 섭외하고, 역할에 맞는 배우를 지정하는 책임을 담당하는 별도의 공연 기획자가 필요하다.
• 공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실히 분리해보는 것이다.

MemberServiceImpl과 OrderServiceImpl이 각자 지정하는 역할도 수행해 곤란하다는 것이다.

 

관심사 분리

 

MemberServiceImpl과 OrderServiceImpl에서 관심사를 분리하는 과정을 살펴볼 거다.

 

관심사 분리를 위해 나오는 것이 AppConfig다.

AppConfig라는 클래스를 따로 두어 환경 설정같은 역할은 모두 여기서 처리해버릴 수 있다.

 

MemberServiceImpl

 

<기존 코드>

 

<수정된 코드>

 

MemberRepository 종류를 지정하지 않고, 대신 생성자를 둔다.

지정하는 책임은 AppConfig에서 하는 거다.

 

 

<AppConfig>-MemberService()의 환경 설정 추가

 

package hello.core;

import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;

public class AppConfig {

    public MemberService memberService(){
        return new MemberServiceImpl(new MemoryMemberRepository()); // 객체 생성해서 지정
    }
}

 

 

AppConfig에서 지정하면 MemberServiceImpl의 생성자를 통해 지정된 내용이 저장되는 거다.

OrderServiceImpl도 마찬가지다.

그래서 정리하면 다음과 같이 개선된 거다.

 

• 설계 변경으로 MemberServiceImpl 은 MemoryMemberRepository를 의존하지 않고, 단지 MemberRepository 인터페이스에만 의존한다. => MemberServiceImpl은 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중할 수 있다.
• MemberServiceImpl의 입장에서 생성자를 통해 어떤 구현 객체(Memory/Fix)가 들어올지는 알 수 없고, 오직 외부(AppConfig)에서 결정된다.

 

<개선된 클래스 다이어그램>

 

 

• 객체의 생성과 연결은 AppConfig가 담당한다.
• DIP 완성: MemberServiceImpl은 MemberRepository인 추상에만 의존하면 되고, 이제 구체 클래스를 몰라도 된다.
• 관심사의 분리: 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었다.

 

 

• AppConfig에서는 MemoryMemberRepository 객체를 생성하고 그 참조값을 MemberServiceImpl을 생성하면서 생성자로 전달한다.
• 클라이언트인 MemberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 우리말로 의존성 주입이라 한다.

 

OrderServiceImpl

 

<수정된 OrderServiceImpl>

 

OrderServiceImpl도 마찬가지로 객체는 생성하지 않고 AppConfig에게 맡긴다.

 

OrderService가 호출되면 OrderServiceImpl()이 반환된다.

 

<AppConfig>-OrderService()의 환경 설정 추가

package hello.core;

import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
import org.springframework.core.OrderComparator;

public class AppConfig {

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

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

}

 

<DI 반영한 OrderServiceImpl>

 

다음과 같이 생성자를 주입

 

실행

 

<MemberApp>

 

AppConfig의 객체를 만들어서 사용하면 더이상 Impl 클래스에 의존하지 않아도 된다.

 

 

<OrderApp>

 

<MemberServiceTest>

 

<OrderServiceTest>

 

이렇게 Impl에도 AppConfig 객체를 사용함으로써 코드 개선이 가능했다.