[스프링 기본] 스프링 핵심 원리 이해2 : 객체 지향 원리 적용

chaen-ing·2024년 6월 2일
BackendSpring
0

Spring 공부

목록 보기
6/13

새로운 할인 정책 개발 & 적용 & 문제점

악덕 기획자 : 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문시 1000원을 할인해주고, 20000원 주문시에 2000원을 할인해주는 거에요!

순진 개발자 : 제가 처음부터 고정 금액 할인은 아니라고 했잖아요.

악덕 기획자 : 애자일 소프트웨어 개발 선언 몰라요? “계획을 따르기보다 변화에 대응하기를”

순진 개발자 : ... (하지만 난 유연한 설계가 가능하도록 객체지향 설계 원칙을 준수했지 후후)

기존 DiscountPolicy 인터페이스에 정률 할인 정책 구현을 추가해서 끼워넣으면 됨

정률 할인 정책 클래스 

package hello.core.discount;

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 : discount함수에서 command+shift+t하면 테스트 자동 생성 가능

package hello.core.discount;

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

import static org.assertj.core.api.Assertions.*;    // Assertions static import 하면 편함
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);   // 1000넣으면 오류 발생
    }

}

적용

    // private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();

OrderServiceImpl에서 구현체만 갈아끼워주면 된다 → 문제 발생

  • 역할 구현 충실하게 분리함
  • 다형성 활용, 인터페이스 구현 객체 분리함
  • OCP, DIP 같은 객체지향 설계 원칙 충실히 준수했는가? → 그래보이지만 사실 아님
    - DIP 위반 : 주문서비스 클라이언트(OrderServiceImpl)은 추상(인터페이스) : DiscountPolicy 뿐만아니라 구체(구현) 클래스인 RateDiscountPolicy에도 의존! 추상 인터페이스에만 의존해야하는데 구체 클래스에도 의존
    - OCP 위반 : 지금 코드는 클라이언트 코드에 변경이 있는 상황DIP를 위반하고 있기때문에 정책 변경시 결국 OCP도 위반하게됨

위 그림과 같이 추상(인터페이스)에만 의존하도록 변경해줘야함

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

그러나 위의 그림과 같이 작성하면 구현체가 없어 실행 불가

널포인트 exception 발생

→ 해결 방안 : 누군가 클라이언트인 OrderServiceImple에 구현객체를 주입해줘야함!

관심사의 분리

예를 들어 로미오와 줄리엣 공연에서 로미오 역할을 누가할지는 배우들이 구하는 것이 아님

→ 관심사의 분리 : 배우와 공연 기획자의 책임을 분리하자

AppConfig 등장 : 구현 객체를 생성하고 연결하는 별도의 설정 클래스

실제 동작에 필요한 구현 객체 생성 → MemberServiceImpl, MemoryMemberRepository, OrderServiceImpl, FixDiscountPolicy

생성한 인스턴스의 참조를 생성자를 통해서 주입

  • MemberServiceImpl : MemoryMemberRepository
  • OrderServiceImpl : MemoryMemberRepository, FixDiscountPolicy
public class AppConfig {
    public MemberService memberService(){
        // 기존에는 MemberServiceImpl 클래스에서 직접 구현체를 넣어줬음
        // 현재는 생성자를 통해서 넣어줌
        return new MemberServiceImpl(new MemoryMemberRepository());
    }

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

MemberServiceImpl

/* 
기존 : 직접 대입하는 방식
public class MemberServiceImpl implements MemberService{
	private final MemberRepository memberRepository = new MemoryMemberRepository();
}
*/

// 변경 : 생성자를 만들어줌
public class MemberServiceImpl implements MemberService{
		private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

구체클래스에 관한 내용은 전혀 없음, MemberRepository 인터페이스만 의존 → DIP 만족

외부에서 생성자를 통해서 넣어줌 : 생성자 주입

OrderServiceImpl

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

여기서 구체클래스에 관한 내용 전혀 없음, DiscountPolicy 인터페이스에만 의존 → DIP 만족

이제 Impl클래스는 생성자를통해 어떤 구현체가 들어올지 모름. 오직 AppConfig에서 결정됨. 즉 이제부터 의존관계에 대해 고민안하고 실행만 하면됨

DIP 만족 : MemberServiceImpl은 MemberRepository인 추상에만 의존 → 관심사의 분리

의존 관계 주입

test

  
	  OrderService orderService;
    MemberService memberService;
    @BeforeEach // 테스트 실행전에 먼저 무조건 실행됨
    public void beforeEach(){
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
        orderService = appConfig.orderService();
    }
    
    @Test
    ...

Test코드에서는 BeforeEach에서 의존 관계 주입해주면 됨

→ 테스트 코드 실행전에 무조건 실행되는 부분

AppConfig 리팩터링

아래와 같은 그림이 보일 수 있도록 리팩터링

public class AppConfig {
    // memberService 역할
    public MemberService memberService(){
        // 기존에는 MemberServiceImpl 클래스에서 직접 구현체를 넣어줬음
        return new MemberServiceImpl(memberRepository());
    }

    // MemberRepository 역할 : MemoryMemberRepository 리턴
    // 만약 추후에 DbMemberRepository로 변경한다면 이부분만 변경해주면됨
    private MemberRepository memberRepository(){
        return new MemoryMemberRepository();
    }

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

    // DiscountPolicy 역할 : FixDiscountPolicy 리턴
    public DiscountPolicy discountPolicy(){
        return new FixDiscountPolicy();
    }
}

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

FixDiscountPolicy → RateDiscountPolicy로 변경

AppConfig 사용으로 인해 사용 영역과 구성 영역을 분리할 수 있게됨

변경이 일어나면 구성영역의 코드만 바꾸면됨

OrderServiceImpl을 전혀 변경하지 않고 바꿀 수 있음

public DiscountPolicy discountPolicy(){
        // return new FixDiscountPolicy();
        // 정액 -> 정률으로 할인 정책 변경
        return new RateDiscountPolicy();
    }

전체 흐름 정리

  • 새로운 할인 정책 개발 : 다형성 덕분에 추가 개발은 문제 X
  • 새로운 할인 정책 적용과 문제점 : 적용하기 위해서 클라이언트 코드를 변경해야함 → DIP, OCP 위반
  • 관심사의 분리 : 배우와 공연기획자를 분리한다고 생각하면됨. AppConfig에서 구현 객체를 생성하고 연결하는 역할을 해줌
  • AppConfig 리팩터링 : 역할이 잘 드러나도록
  • 새로운 구조와 할인 정책 적용 : 사용영역을 건드리지 않고 사용영역(AppConfig)만 변경해서 FixDiscountPolicy → RateDiscountPolicy로 수정

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

SRP 단일 책임 원칙

기존 클라이언트 객체 : 구현 객체 생성, 연결, 실행 → 너무 많은 책임

→ AppConfig가 구현 객체 생성 및 연결 역할을 담당

DIP 의존관계 역전 원칙

클라이언트 코드가 추상인터페이스 뿐만아닌 구체클래스에도 의존 하고 있었음

→ 클라이언트 코드가 추상 인터페이스만 의존하도록 변경 : 아무것도 못함 NullPointException

→ AppConfig에서 의존 관계를 주입해주도록 변경해줌

OCP 확장에는 열려있고 변경에는 닫혀있음

사용영역과 구성영역으로 나눔

FixDiscountPolicy → RateDiscountPolicy로 변경했지만 구성영역에서만 변경하고 사용영역은 변경 안함

IoC, DI, 그리고 컨테이너

IoC 제어의 역전

기존 프로그램 : 구현 객체가 프로그램의 제어 흐름을 조종. 자연스러운 흐름

AppConfig 등장 이후 : 구현 객체는 실행 역할만 담당. 제어 흐름은 AppConfig가 모두 담당한다.

심지어 OrderServiceImpl도 AppConfig가 생성

프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)라고 함

  • 프레임 워크 : 내가 작성한 코드를 제어하고, 대신 실행 ex) @BeforeEach, @Test (JUnit)
  • 라이브러리 : 내가 작성한 코드가 직접 제어의 흐름을 담당

DI 의존 관계 주입

OrderServiceImpl은 DiscountPolicy 인터페이스에 의존 → 어떤 구현 객체가 사용될지 모름(정액 할인 정책인지, 정률 할인 정책인지… 모름!)

의존 관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계를 분리하여 생각해야함

정적인 클래스 의존 관계 : 어플리케이션 실행하지 않아도 분석가능한 의존관계

OrderServiceImpl이 MemberRepository, DiscountPolicy를 의존하는 중이라는 것을 알 수 있음

→ 하지만 실제로 어떤 구체클래스가 주입될지는 알 수 없음

동적인 객체 인스턴스 의존 관계

의존 관계 주입 : 어플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것

  • 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스 변경가능
  • 정적인 클래스 다이어그램의 의존관계를 변경하지 않고, 동적 객체 인스턴스 의존관계를 쉽게 변경 가능

IoC 컨테이너, DI 컨테이너

: AppConfig처럼 객체를 생성하고 관리하면서, 의존관계를 주입해주는 것

최근에는 의존관계 주입에 초점을 맞춰 주로 DI 컨테이너라고 함 (or 어셈블러, 오브젝트 팩토리 등으로도 부름)

스프링으로 전환하기

@Configuration
public class AppConfig {

    // memberService 역할
    @Bean
    public MemberService memberService(){
        // 기존에는 MemberServiceImpl 클래스에서 직접 구현체를 넣어줬음
        return new MemberServiceImpl(memberRepository());
    } 
    ...

@Configuration : 설정정보

@Bean : 각 메소드마다 적어주면됨. 스프링 컨테이너에 저장됨

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

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
MemberService memberService = applicationContext.getBean("memberService",MemberService.class);
OrderService orderService = applicationContext.getBean("orderService",OrderService.class);

ApplicationContext : 스프링 컨테이너

스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정 정보로 사용

→ 여기서 @Bean이라고 적인 메소드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록

→ 이렇게 등록된 객체 : 스프링 빈

스프링빈은 @Bean이 붙은 메소드 명을 이름으로 사용 → getBean(”메소드 이름”, 클래스) 사용하는 이유

이전에는 개발자가 필요한 객체를 AppConfig를 사용해서 직접 조회했지만, 이제는 컨테이너를 통해 필요한 객체를 찾아야함 → getBean을 사용해서 찾음

즉, 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경된것

인프런 스프링 핵심 원리 기본편 - 김영한 강의를 듣고 정리한 내용입니다

profile
chaen-ing
💻 개발 공부 기록장
이전 포스트

[스프링 기본] 스프링 핵심 원리 이해 1

다음 포스트

[스프링 기본] 스프링 컨테이너와 스프링 빈

0개의 댓글

관련 채용 정보