Spring - 스프링 핵심 원리 이해2 - 3(객체 지향 원리 적용)

AppConfig 리팩토링

• 현재 AppConfig는 중복이 있고, 역할에 따른 구현이 잘 안 보임

기대하는 그림

리팩토링 후

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberSerivce;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {
    public MemberSerivce memberSerivce() {
        return new MemberServiceImpl(memberRepository());
    }

    private MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

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

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

• new MemoryMemberRepository()이 부분이 중복 제거
  • MemoryMemberRepository를 다른 구현체로 변경할 때 한 부분만 변경하면 된다!

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

• 정률 할인 정책(Fix)에서 정률 할인 정책(Rate)로 변경하자

사용, 구성의 분리 다이어그램

할인 정책 변경 다이어그램

할인 정책 변경 코드

public class AppConfig {
    public MemberSerivce memberSerivce() {
        return new MemberServiceImpl(memberRepository());
    }

    private MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

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

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

• AppConfig에서 할인 정책을 담당하는 구현은 FixDiscountPolicy에서 RateDiscountPolicy로 변경
  • 앱의 구성을 변경할 때는 AppConfig에서만 변경하면 됨
  • 클라이언트 코드(OrderServiceImpl외 구현체)를 건들지 않아도 된다!

현재까지 전체 흐름

새로운 할인 정책 개발

• 다형성 덕분에 새로운 할인 정책 코드를 추가로 개발하는 것에 문제가 없었다
  • 하지만 새로운 할인 정책을 적용하려 하니 클라이언트 코드(주문 서비스 구현체)도 함께 변경했어야 했다.
    • 주문 서비스 클라이언트가 인터페이스(DiscountPolicy)뿐 아니라 구체 클래스인 FixDiscountPolicy도 함께 의존 -> DIP 위반

관심사 분리

• 기존에는 클라이언트가 의존하는 서버 구현 객체를 직접 생성하고 실행
• AppConfig를 통해 앱의 전체 동작 방식을 구성
  • 구현 객체 생성, 연결
  • 클라이언트는 자신의 역할을 실행하는 것에 집중한다.(권한이 줄어들고, 책임이 명확해졌다)

AppConfig 리팩토링

• 구성 정보에서 역할과 구현을 명확하게 분리
  • 역할이 잘 드러나게 함
• 중복 제거(new MemoryMemberRepository())

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

• 정액 할인 정책에서 정률 할인 정책으로 변경(Fix -> Rate)
• AppConfig의 등장으로 애플리케이션이 사용 영역과, 객체를 생성하고 구성하는 영역으로 분리
• 할인 정책을 변경해도 AppConfig만 변경하면 된다.

좋은 객체지향 설계의 5가지 원칙 적용

SRP 단일 책임 원칙

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

• 클라이언트는 직접 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임이 있었다
• SRP 단일 책임 원칙을 따르기 위해 관심사를 분리
  • AppConfig를 만들어 구현 객체를 생성하고 연결하는 책임을 맡김
  • 클라이언트는 실행하는 책임만 담당

DIP 의존관계 역전 원칙

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.

• 새로운 할인 정책을 개발하고 적용하려니 클라이언트 코드도 변경이 필요했음
  • 기존 코드는 DIP를 지키며 인터페이스(DiscountPolicy)에 의존하는 것 같았지만, 구체화 구현 클래스(FixDiscountPolicy)에도 함께 의존
• 일단 클라이언트 코드를 인터페이스(DiscountPolicy)에만 의존하도록 변경
  • 하지만 인터페이스만으로는 아무것도 실행할 수 없음
• AppConfig가 FixDiscountPolicy 객체 인스턴스 클라이언트 코드를 대신 생성하여 클라이언트 코드에 의존관계 주입
• DIP 원칙을 따르며 문제 해결!

OCP

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

• 다형성을 사용하고 클라이언트가 DIP를 지켰다
• 앱을 사용 영역과 구성 영역으로 나눔
• AppConfig가 의존 관계를 변경해서 클라이언트에 주입하기 때문에 클라이언트 코드는 변경할 필요 없다
• 새롭게 확장해도 사용 영역의 변경은 닫혀 있음!

출처 : 인프런 김영한 지식공유자님의 스프링 완전 정복 로드맵 강의