예제를 통한 OCP, DIP 위반 (2)

문제 인식

만든 예제 프로그램이 하나의 공연이라고 생각해보자.
우리는 객체지향 설계 원칙을 지키면서 다형성을 이용하여 인터페이스와 구현체를 분리하였다.
근데 아래와 같이 짠 코드는 로미오 역할(인터페이스)을 하는 디카프리오(구현체)가 줄리엣 역할을 하는 배우(구현체)를 섭외하는 것과 같다.
인터페이스에만 의존하게 만들어야 로미오 역할이 누구든, 줄리엣 역할이 누구든 똑같은 공연을 할 수 있다.

public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository = new MemoryMemberRepository();
private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}

DI(Dependency Injection)

배우와 기획자의 역할을 분리해보자!

구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스인 AppConfig 클래스를 만든다.

public class AppConfig {

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

AppConfig 코드에 맞게 OrderServiceImpl 코드도 변경해주었다.

private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;

public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

이제 service 에서는 어떤 구현체가 들어오는 지 알 수 없다.
service 에서 new 하지 않고, 생성자를 통해 어떤 객체가 들어올 지는 Appconfig가 결정한다. 즉, 외부에서 결정한다.
드디어 우리는 구현체를 의존하지 않으면서 OCP, DIP 원칙을 지키게 되었다.

이것을 클라이언트인 service 입장에서 보면 의존관계를 외부에서 주입한다고 해서 DI(Dependency Injection). 의존관계 주입 또는 의존성 주입이라고 한다.

Appconfig 리팩토링

AppConfig 클래스를 봤을 때 중복이 생기고 역할에 따른 구현이 명확하지 않다.
MemberRepository나 DiscountPolicy 구현체를 변경할 때 한 부분만 변경하면 되고, 애플리케이션의 전체적인 구조를 파악하기 명확해지도록 리팩토링하였다.

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

[참고] 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술