Spring gradle project 스프링 핵심 원리 기본편 | 객체 지향 원리 적용

---

본 포스팅은 인프런에 있는 인터넷 강좌인,

김영한 강사님의 스프링 핵심 원리 기본편을 공부하며,

개인적으로 공부하고, 정리하는 용도로 포스팅을 해보겠다.

 

[이전 포스팅 목록]

Spring gradle project 환경설정 및 회원 가입 서비스 예제 만들기
Spring gradle project 주문/할인 도메인 설계

3. 객체 지향 원리 적용 (1)

새로운 할인 정책 개발

• 아래 문구는 강의에서 나오는 강의 자료다.

• 실무에서 악덕은 기획자든 개발자든 누가 될지 모른다.
  (개인적으로 이렇게 예시를 들어가며 말해주는 기획자는 악덕까지는 아닌 듯하다.)
• 전에 사용했던 FixDiscountPolicy 객체에 이어, 할인 정책이 바뀐다는 상황을 고려하여 RateDiscountPolicy라는 객체를 새로 만들어주었다.

RateDiscountPolicy 추가

package hello.core.discount;

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

public class RateDiscountPolicy implements DiscountPolicy{

    private int discountPercent = 10; // 10프로 할인

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

테스트 작성

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.assertThat;

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가 아니면 10% 할인이 적용되지 않아야 한다.")
    void vip_x(){
        //given
        Member member = new Member(2L, "memberBASIC", Grade.BASIC);
        //when
        int discount = discountPolicy.discount(member, 10000);
        //then
        assertThat(discount).isEqualTo(0);
    }

}

• VIP와 일반 회원 간 정책 적용을 잘 테스트할 수 있었다.
• 우리는 기존에 OrderService 인터페이스를 상속받은 OrderServiceImple이라는 구현체를 사용하고 있었다. 그리고 이 구현체 안에서 할인 정책을 선택했었는데, 새로운 정책에 따라 위에 코드처럼 RateDiscountPolicy로 구현체를 지정해 주었다.
• 하지만 이 코드는 SOLID 방식에서 두 가지나 위반하고 있다.
  • DIP 위반 : 클래스 의존관계를 봤을 때 지금 클래스는 인터페이스뿐만 아니라 구현체에도 의존하고 있기 때문이다. 한마디로, DiscountPolicy 인터페이스에만 의존하지만 지금은 FixDiscountPolicy와 RateDiscountPolicy 둘 다 의존하고 있다.
  • OCP 위반 : 할인 정책을 바꾸는 과정에서 클라이언트 코드에 영향을 주고 있다. 예를 들어, 직접 OrderServiceImple에 들어가서 Policy를 직접 바꿔주고 있는데, FixDiscountPolicy를 RateDiscountPolicy로 변경하는 순간 OrderServiceImpl의 코드도 함께 변경해야 한다

인터페이스에만 의존하도록 코드 변경

• 아래 코드와 같이 DIP를 위반하지 않도록, 인터페이스에만 의존하도록 의존관계를 변경하면 된다.

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

• 하지만 이렇게만 하면 구현체가 없기 때문에 정상적으로 코드가 실행할 수 없다.
• 무언가가 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해야 한다.

 

관심사 분리

• 애플리케이션을 하나의 공연이라 생각해 볼 때, 각각의 인터페이스를 배역(배우 역할)이라 생각하자.
  그런데! 실제 배역 맞는 배우를 선택하는 것은 누가 하는가?
• 로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할지 줄리엣 역할을 누가 할지는 배우들이 정하는 게 아니다.
• 이전 코드는 마치 로미오 역할(인터페이스)을 하는 레오나르도 디카프리오(구현체, 배우)가 줄리엣 역할(인터페이스)을 하는 여자 주인공(구현체, 배우)을 직접 초빙하는 것과 같다. 디카프리오는 공연도 해야 하고 동시에 여자 주 인공도 공연에 직접 초빙해야 하는 다양한 책임을 가지고 있다.
• 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다. 디카프리오는 어떤 여자 주인공이 선택되더라도 똑같이 공연을 할 수 있어야 한다.
• 공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 지정하는 책임을 담당하는 별도의 공연 기획자가 나 올시점이다.
  공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실히 분리하자.
• 코드에서의 공연 기획자는 AppConnfig라는 설정 클래스가 되겠다.

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

• 의존성 주입(DI) : MemberService와 OrderService 구현체(각각 MemberServiceImpl과 OrderServiceImpl)는 생성자를 통해 필요한 의존성이 주입되어 인스턴스화된다.
• 제어의 역전(IoC) : 서비스가 자신의 의존성, 예를 들어 레포지토리나 할인 정책과 같은 것들을 인스턴스화하는 대신, AppConfig 클래스에 의해 런타임에 제공된다. 이 제어의 역전은 Spring 프레임워크의 구성 요소 관리 방식의 핵심으로, 코드를 더 모듈화 하고 테스트 및 유지 관리하기 쉽게 만들고 있다.
• AppConfig 클래스는 MemberServiceImpl과 OrderServiceImpl에 MemoryMemberRepository를 사용하도록 하기 때문에, 각 서비스는 자신의 MemoryMemberRepository의 중복된 인스턴스를 가지게 된다.
• 지금은 각 클래스에 생성자가 없어서 컴파일 오류가 발생한다. 아래 코드에 생성자를 주입하겠다.

MemberServiceImpl - 생성자 주입

package hello.core.member;

public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;
    
    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    
    public void join(Member member) {
        memberRepository.save(member);
    }
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

• 설계 변경으로 MemberServiceImpl은 MemoryMemberRepository를 의존하지 않고 MemberRepository 인터페이스만 의존한다.
• MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 주입될지 알 수 없다.
• MemberServiceImpl의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부 클래스인 AppConfig에서 결정된다.

클래스 다이어그램

• 객체의 생성과 연결은 AppConfig 가 담당한다.
• DIP 완성 : MemberServiceImpl은 MemberRepository인 추상(인터페이스)에만 의존하면 된다.
• 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었다.

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

 

• appConfig 객체는 memoryMemberRepository 객체를 생성하고, 그 참조값(x001) memberServiceImpl을 생성하면서 생성자로 전달한다.

OrderServiceImpl - 생성자 주입

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;

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에는 MemoryMemberRepository, FixDiscountPolicy 객체의 의존관계가 주입된다.

MemberApp에서 AppConfig 실행

package hello.core;

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

public class MemberApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        
        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에서 AppConfig 실행

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.order.Order;
import hello.core.order.OrderService;

public class OrderApp {
    public static void main(String[] args) {
    
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();
        
        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);
    }
}

 

테스트 코드

package hello.core.member;

import hello.core.AppConfig;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class MemberServiceTest {
    MemberService memberService;

    /**
     * BeforeEach : 테스트 실행전 무조건 실행
     */
    @BeforeEach
    public void beforeEach(){
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
    }

    @Test
    void join() {
        //given
        Member member = new Member(1L, "memberA", Grade.VIP);

        //when
        memberService.join(member);
        Member findMember = memberService.findMember(1L);

        //then
        Assertions.assertThat(member).isEqualTo(findMember);
    }
}

 

정리

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

이렇게 외부의 AppConfig를 통해서 계속해서 나오는

의존성 주입(DI)과 제어의 역전(IoC)을 알아봤다.

하지만 이런 AppConfig도 중복이 발생하고,

역할에 따른 구현이 명확하지 않다.

다음 포스팅에서는 이런 AppConfig를 리팩토링 하면서,

역할에 따른 구현을 명확하게 표현해 보도록 하겠다.

끝.