#4 관심사의 분리(SOC), 의존성 주입(DI)

이 글은 2021.08.01 - [Backend/Spring Core] - #3 스프링 핵심 원리 - 예제 만들기와 이어지는 내용입니다.

#3 스프링 핵심 원리 - 예제 만들기

 

# 한 객체가 너무 많은 책임을 가지고 있다.

현실에서 일어나는 대규모 공연을 생각해보자. 각각의 인터페이스를 배역(역할)이라고 생각할 때, 그 배역을 연기하는 구현체(연기자)를 선택하는 것은 누가 담당할까? 이는 감독이 결정하는 것이지 배우들이 직접 결정하는 것이 아니다.

 

이전의 코드 방식은 마치 주인공의 연기자(구현체)가 다른 역할을 맡을 사람(구현체)을 직접 초빙하여 구하는 방식과 같다. 즉 연기자는 공연도 해야하고, 자신과 함께 연기할 다른사람도 함께 뽑고, 관리해야한다. 즉, 감독이 연기도하고 섭외도하고 사람들 간의 관계도 정리해야하는 다양한 책임을 혼자 지고있다.

 

# 관심사를 분리하자, SOC(Separation Of Concerns) 

공연에서 담당 배우(구현체)가 바뀌었다고 공연의 주인공의 행동(역할)이 변경되지 않는다.

• 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다.
• 연기자는 다른 배역을 맡게 되더라도 공연을 할 수 있어야한다.
• 공연을 구성하고, 담당 배우를 섭외하는 것은 별도의 공연 기획자가 담당해야한다.
• 배우와 공연 기획자의 책임을 확실하게 분리하자.

즉, 공연기획자를 담당하는 AppConfig 클래스를 만들면 해결할 수 있다.

public class AppConfig {
	// MemberService를 담당하는 기획자
    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
    }

	// OrderService를 담당하는 기획자
    public OrderService orderService() {
        return new OrderServiceImpl(
                new MemoryMemberRepository(),
                new FixDiscountPolicy());
    }
}

AppConfig에서 구현체를 주입할 수 있게 아래와 같이 인터페이스를 변경하였다.

public class MemberServiceImpl implements MemberService {
    // [... = new 구현체 ]처럼 직접 할당해서 구현체를 의존하는 부분을 없애주었다
    public final MemberRepository memberRepository;

    // 그 대신 AppConfig에서 구현체를 주입할 수 있게 생성자를 만들어주었다.
    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository
    }

    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

이렇게 생성자를 이용해 구현체, 즉 의존성을 주입해주는 식으로 바뀌었다. 구현체가 바뀐다 하더라도 클라이언트는 인터페이스(역할)에만 의존하기에 전혀 상관없다.  

• AppConfig는 앱의 실제 동작에 필요한 구현 객체를 생성한다.
  - ( MemberServiceImpl, MemoryMemberRepository, OrderServiceImpl, FixDiscountPolicy )
  
  
• AppConfig는 생성한 객체의 인스턴스의 참조를 생성자를 통해서 주입, 연결해준다.
  - MemberServiceImpl -> MemoryMemberRepositroy
  - OrderServiceImpl -> MemoryMemberRepository, FixDiscountPolicy
• 즉, 인터페이스에만 의존한다. 즉 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 된다. 관심사를 분리하여 코드를 만들 수 있다.

---

# DI 의 등장 (Dependency Injection)

AppConfig 객체를 통해서 memoryMemberRepository 객체를 생성하고 참조값을 memberServiceImpl의 생성자로 주입한다. 아래의 코드에서 구현체(memoryMemberRepository)의 소스코드가 변경되다고 해서, 바뀌어야 할 부분이 있을까?

public interface MemberService {
    void join(Member member);
    Member findMember(Long memberId);
}

public class MemberServiceImpl implements MemberService {
    // [... = new 구현체 ]처럼 직접 할당해서 구현체를 의존하는 부분을 없애주었다
    public final MemberRepository memberRepository;

    // 그 대신 AppConfig에서 구현체를 주입할 수 있게 생성자를 만들어주었다.
    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

이처럼 클라이언트(MemberServiceImpl)의 입장에서 보면, 마치 의존관계를 외부에서 주입하는 것 같다고 하여 이러한 방식의 설계를 DI(Dependency Injection), 의존성 주입이라고 부르게 되었다.

 

---

# 기획자, AppConfig를 리팩토링해보자

현재 AppConfig는 단순하게 작성한거라, 객체지향에서 말하는 좋은 코드라고 보기에는 어렵다. 코드의 중복이 있고 역할에 따른 구현을 알기 어렵기 때문이다. 이를 우리가 배운 방법으로 리팩토링해보자.

// 기존의 코드
public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
    }

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

우리가 만든 설계도에 맞춰 AppConfig 코드를 변경한다.

/*
    구현체 생성(memberRepository)의 중복 코드를 제거하고 
    AppConfig 만으로 역활가 구현클래스를 알수있게 바뀌었다.
 */
public class AppConfig {
    // MemberService
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    // OrderService
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }

    // Repository
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    // DiscountPolicy
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

그리고 테스트 코드도 new로 생성하는게 아닌, AppConfig를 연결하는 방식으로 바꿔주자.

@DisplayName("OrderService 클래스의")
class OrderServiceTest {
    private OrderService orderService;
    private MemberService memberService;

    @BeforeEach
    void beforeEach() {
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
        orderService = appConfig.orderService();
    }
    ... 생략 ...

이렇게 까지 해주면, 우리는 드디어 DIP와 OCP를 만족하는 설계를 했다고 말할 수 있다.

• 의존성 주입을 통해 인터페이스(역할)만을 보고 개발할 수 있게 바뀌었다.
• 확장에는 열려있으나 수정에는 닫혀있는 코드를 작성하였다. 

  ---

# 새로운 구조와 악덕 기획자의 할인정책 적용

다시 처음으로 돌아가서, 이전 글에서 말했던 새로운 할인정책을 적용시켜보자. 어떤 부분을 수정하면 될까?

public class AppConfig {
	... 생략 ...

    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();
    	return new RateDiscountPolicy();
    }
}

즉, AppConfig라는 감독 역할의 객체가 생김으로서 앱 자체가 서비스 사용영역과 객체를 구성(Configuration)하는 영역으로 분리되었음을 알 수 있다.

FixDiscount -> RateDiscount로 변경했다 한들, 사용영역 코드는 전혀 영향받지 않는다.

 

---

# 설계의 발전, 객체지향 적용

우리가 이전 글과 여기까지 했던 고민들은, 실제 자바 개발자들이 고민했던 내용과 동일하다.

1. 객체지향 개념, 다형성을 구현

2. 새로운 할인 정책 개발 => 인터페이스를 이용해서 다형성을 '구현 한 것'처럼 보임.

3. 새로운 할인 정책의 문제점 => 구현체를 변경하면, 클라이언트 코드도 변경해야함. DIP 위반

4. 해결책. 관심사의 분리 => 감독 역할의 AppConfig의 등장.

5. AppConfig도 객체지향적으로 리펙토링

 

모를 수도 있겠지만, 문제를 하나하나 해결하면서 우리는 자연스럽게 SRP, DIP, OCP를 적용시켰다.

 

@1. SRP 단일 책임 원칙

한 클래스는 하나의 책임만 가져야 한다.

[회원-주문]은 클라이언트 객체에서 직접 구현체를 생성, 연결하는 과도한 책임을 가지고 있었다. 이를 SRP 원칙에 따라 관심사를 분리하였고, 구현체를 생성하고 연결하는 책임을 AppConfig로 분리하였다. 이제 클라이언트 객체는 [회원-주문]서비스라는 하나의 로직을 수행하는 책임만 맡게 되었다.

 

@2. DIP 의존관계 역전 원칙

추상화에 의존해야지, 구체화에 의존하면 안된다.

처음의 설계에서는 각각의 구현체들이 필요한 다른 역할을 '직접 대입'해야 했었다. 즉 다른 구현체에 의존성이 생기며 DIP 원칙을 지키지 못했다. 하지만 AppConfig를 할인정책이나 회원조회저장소가 생성자를 통해 AppConfig에서 주입하도록 바꾸면서 이제 클라이언트 객체는 다른 구현체를 전혀 몰라도 인터페이스(추상화)에 의존하여 코드를 작성할 수 있게 되었다. 

 

@3. OCP 개방-폐쇄 원칙

소프트웨어 요소는 확장에는 열려있으나, 변경에는 닫혀있어야 한다.

처음에는 말도안되는 말이라고 생각했을 수 있다. 아무리 인터페이스를 사용한다고 한들, 변경을 안하고 어떻게 확장을 할까? 우리는 이미 답을 알고있다. 다형성을 사용함으로써 클라이언트가 DIP를 지키도록만들었고, 앱의 사용영역과 구성(config)영역을 분리시켜 개발 할 수 있게 되었다.

 

이제 할인정책변경이나 회원 저장소가 더 많은 기능을 가진 구현체로 바뀌더라도, AppConfig 구성영역에서 의존관계 주입만 바꿔주게되면 클라이언트의 코드의 수정없이 바꿀 수 있다. 즉 소프트웨어 요소를 새롭게 확장, 변경하더라도 서비스 사용영역의 변경은 닫혀있게 된다.

 

 

이제 다음 글에는 객체지향 설계와 더불어, 스프링의 핵심인 IoC, DI 그리고 컨테이너에 대해 배워보도록 합시다.