[스프링 핵심 원리 - 기본편] #3. 스프링 핵심 원리 이해2 - 객체 지향 원리 적용 (1)

[6om1n]

새로운 할인 정책 개발

새로운 할인 정책을 확장해보자

악덕 기획자 : 서비스 오픈 직전에 할인 정책을 고정 금액 할인이 아닌 좀 더 합리적인 주문 금액 당 할인하는 정률 % 할인으로 변경하고 싶어요.
ex) 기존에는 VIP가 주문하는 금액에 상관없이 1000원을 할인하였는데 새로 나온 정책으로 10000원 주문 시 1000원을 할인해주고, 20000원 주문 시 2000원을 할인해주고 싶어요.
순진 개발자 : 처음부터 고정 금액 할인은 아니라고 했잖아요.
악덕 기획자 : 애자일 소프트에어 개발 선언 모르시나요? "계획을 따르기보다 변화에 대응하기를"
순진 개발자 : 하지만 유연한 설계가 가능하도록 객체 지향 설계 원칙을 준수하였기에 쉽지 않을까?

📌 참고 : 애자일 소프트웨어 개발 선언 https://agilemanifesto.org/iso/ko/manifesto.html

RateDiscountPolicy 추가

• 할인 정책을 나타내는 DiscountPolicy 아래에 RateDiscountPolicy 구현을 추가하였다.

RateDiscountPolicy 코드 추가

import hello.core.member.Grade;
import hello.core.member.Member;

public class RateDiscountPolicy implements DiscountPolicy{
    private int discountPercent = 10;

    @Override
    public int discount(Member member, int price) {
       if (member.getGrade() == Grade.VIP) {
           return price * discountPercent / 100;
       } else {
           return 0;
       }
    }
}

테스트 작성 test/RateDiscountPolicyTest

package hello.core.discount;
import hello.core.member.Grade;
import hello.core.member.Member;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;
import static org.junit.jupiter.api.Assertions.*;

class RateDiscountPolicyTest {
    RateDiscountPolicy discountPolicy = new RateDiscountPolicy();
    @Test
    @DisplayName("VIP는 10% 할인이 적용되어야 한다.")
    void vip_o() {
        //given
        Member member = new Member(1L, "memberVIP", Grade.VIP);
        //when
        int discount = discountPolicy.discount(member, 10000);
        //then
        assertThat(discount).isEqualTo(1000);
    }

    @Test
    @DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다.")
    void vip_x() {
        //given
        Member member = new Member(2L, "memberBASIC", Grade.BASIC);
        //when
        int discount = discountPolicy.discount(member, 10000);
        //then
        assertThat(discount).isEqualTo(0);
    }
}

테스트를 진행할 때 항상 실패하는 테스트도 만들어 보아야한다.

---

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

방금 추가한 할인 정책을 적용

• 할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야한다.

public class OrderServiceImpl implements OrderService {
// private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
 private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}

문제점 발견

✔️ 우리는 역할과 구현을 충실하게 분리했다.
✔️ 다형성도 활용하고, 인터페이스와 구현 객체를 분리했다.
❌ OPC,DIP 같은 객체지향 설계 원칙을 준수한 것 같아보이지만 아니다.
❌ DIP: 주문서비스 클라이언트(OrderServiceImpl) 는 DiscountPolicy 인터페이스에 의존하면서 DIP를 지킨 것 같지만, 추상 (인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존 하고 있다.
❌ 지금 코드는 기능을 확장해서 변경하면 클라이언트 코드에 영향을 준다. 따라서 OCP를 위반한다.

• 기대했던 의존 관계

• 실제 의존 관계
  

지금까지 단순히 DiscountPolicy 인터페이스만 의존한다고 생각했지만, 클라이언트인 OrderServiceImpl 이 DiscountPolicy 인터페이스 뿐만 아니라 FixDiscountPolicy 인 구체 클래스도 함께 의존 하고 있다.
❗ DIP 위반이다.

• 정책 변경
  
  ⭐ 그래서 FixDiscountPloicy 를 RateDiscountPolicy 로 변경하는 순간 OrderServiceImpl 소스코드도 함께 변경해야한다. --> OCP 위반

따라서 인터페이스에만 의존하도록 설계를 변경해야한다.

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

이 코드의 문제점 : DIP는 지켰지만, 객체가 없어 돌아가지 않는다. 즉 널 포인터 예외가 발생한다.
❗ 해결 방안 : 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy 의 구현 객체를 대신 생성하고 주입해줘야한다.

---

관심사의 분리

• 애플리케이션을 하나의 공연이라고 생각하자. 각각 인터페이스를 배역(배우 역할)이라 생각하자. 그 때 실제 배역 맞는 배우를 선택하는 것은 누구의 역할인가?
• 로미오와 줄리엣 공연이라고 할 때 누가 로미오, 줄리엣 역할을 할 것인지를 배우가 정하는 것이 아니다. 이 전에 구현했던 코드는 레오나르도 디카프리오가 공연도 해야하고 동시에 여자 주인공도 직접 초빙해야 하는 것과 같다. --> 다양한 책임 을 가지고 있다.
• 이 때 필요한 것이 관심사의 분리이다

AppConfig 등장

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

• AppConfig

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;

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

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

• AppConfig 는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성 한다.
  • MemberServiceImpl
  • MemoryMemberRepository
  • OrderServiceImpl
  • FixDiscountPolicy
• AppConfig 는 생성한 객체 인스턴스의 참조 (레퍼런스)를 생성자를 통해서 주입(연결) 해준다.
  • MemberServiceImple -> MemoryMemberRepository
  • OrderServiceImpl -> MemoryMemberRepository , FixDiscountPolicy
    📌 지금은 각 클래스에 생성자가 없어 컴파일 오류 발생. 바로 다음 코드에 이어서 생성자 생성

MemberServiceImpl - 생성자 주입

public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;

    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 은 MemoryMemberRepository 를 의존하지 않는다.
• 단지 MemberRepository 인터페이스만을 의존한다.
• MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어 올지는 알 수 없다.
• MemberServiceImpl 의 생성자를 통해서 어떤 구현 객체를 주입할지는 외부 (AppConfig) 에서 결정된다.
• MemberServiceImpl 은 의존관계에 대한 고민은 외부 에 맡기고, 실행에만 집중 하면 된다.

클래스 다이어그램

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

회원 객체 인스턴스 다이어그램

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

OrderServiceImpl - 생성자 주입

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
import hello.core.member.MemoryMemberRepository;

public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

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

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

• 설계 변경으로 OrderServiceImpl 은 FixDiscountPolicy 를 의존하지 않는다!
• 단지 DiscountPolicy 인터페이스만 의존한다.
• OrderServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다.
• OrderServiceImpl 의 생성자를 통해서 어떤 구현 객체을 주입할지는 오직 외부( AppConfig )에서 결정한다.
• OrderServiceImpl 은 이제부터 실행에만 집중하면 된다.
• OrderServiceImpl 에는 MemoryMemberRepository , FixDiscountPolicy 객체의 의존 관계가 주입된다.

AppConfig 실행

• MemberApp

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;

public class MemberApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        //MemberService memberService = new MemberServiceImpl();
        Member member= new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("find Member = " + findMember.getName());
    }
}

• OrderApp

package hello.core;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.order.Order;

import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class OrderApp {
    public static void main(String[] args) {

        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();

       // MemberService memberService = new MemberServiceImpl(null);
       // OrderService orderService = new OrderServiceImpl(null, null);
        long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);
        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order);
    }
}

• 테스트 코드 오류 수정 MemberServiceTest

class MemberServiceTest {
 MemberService memberService;
 @BeforeEach
 public void beforeEach() {
 AppConfig appConfig = new AppConfig();
 memberService = appConfig.memberService();
 }
}

• 테스트 코드 오류 수정 OrderServiceTest

class OrderServiceTest {
 MemberService memberService;
 OrderService orderService;
 @BeforeEach
 public void beforeEach() {
 AppConfig appConfig = new AppConfig();
 memberService = appConfig.memberService();
 orderService = appConfig.orderService();
 }
}

• 테스트 코드에서 @BeforeEach 는 각 테스트를 실행하기 전에 호출된다.

📌 정리

• AppConfig 를 통해서 관심사를 확실하게 분리했다.
• AppConfig 는 구체 클래스를 선택한다. 즉, 애플리케이션이 어떻게 동작해야 할 지 전체 구성을 책임진다.
• OrderServiceImpl 은 기능을 실행하는 책임만 지면 된다.

---

AppConfig 리팩터링

• 현재 AppConfig 를 보면 중복 이 있고, 역할에 따른 구현 이 잘 안보인다.
  
• 리팩터링 전

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;
public class AppConfig {
 public MemberService memberService() {
 return new MemberServiceImpl(new MemoryMemberRepository());
 }
 public OrderService orderService() {
 return new OrderServiceImpl(
 new MemoryMemberRepository(),
 new FixDiscountPolicy());
 }
}

• 리팩터링 후

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberRepository;
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;

public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

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

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

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

• new MemoryMemberRepository() 이 부분이 중복 제거되었다. 이제 MemoryMemberRepository 를 다른 구현체로 변경할 때 한 부분만 변경하면 된다.
• AppConfig 를 보면 역할과 구현 클래스가 한눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다.

---

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

• 정액 할인 정책을 정률 할인 정책으로 변경하자

• AppConfig 의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성하는 영역으로 분리되었다.

• 그림 - 사용, 구성의 분리
  

• 그림 - 할인 정책의 변경
  

• 할인 정책을 변경하면 AppConfig 구성 영역의 코드만 고치면 된다.
• 사용 영역에 있는 코드들은 전혀 고칠 필요가 없다.
• OrderServiceImpl 은 클라이언트 코드를 전혀 변경 할 필요가 없이 어플리케이션 기능을 확장할 수 있다.
• **OCP 와 DIP 를 모두 만족하는 코드를 완성 시켰다. **

• 할인 정책 변경 구성 코드

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberRepository;
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;

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

• AppConfig 에서 할인 정책 역할을 담당하는 구현을FixDiscountPolicy-> RateDiscountPolicy 객체로 변경했다.
• 이제 할인 정책을 변경해도, 애플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 된다. 클라이언트 코드인 OrderServiceImpl 를 포함해서 사용 영역의 어떤 코드도 변경할 필요가 없다.
• 구성 영역은 당연히 변경된다. 구성 역할을 담당하는 AppConfig를 애플리케이션이라는 공연의 기획자로 생각하자. 공연 기획자는 공연 참여자인 구현 객체들을 모두 알아야 한다