[강의] 스프링 핵심 원리- 기본편 2

inf.run/wr1v

스프링 핵심 원리 - 기본편 - 인프런 | 강의

출처:  김영한 강사님 스프링 핵심 원리-  기본편

 

3. 스프링 핵심 원리 이해1 - 객체 지향 원리 적용

- 새로운 할인 정책 개발

진짜... 웃겨....ㅋㅋㅋㅋㅋㅋㅋ 아나 저 마지막 멘트가 진심 웃김

저번엔 고정 금액 할인을 만들었으니 이번엔 정률 금액 할인 클래스 RateDiscountPolicy를 구현해 보았다.

 

테스트코드

//RateDiscountPolicyTest.java
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(1L, "memberVIP", Grade.BASIC);
        //when
        int discount = discountPolicy.discount(member, 10000);
        //then
        assertThat(discount).isEqualTo(1000); // 오류나야한다. 할인금액은 0이어야 하기 때문
    }
}

테스트 코드 만들 때 ctrl+alt+t

모르겠으면 냅다 alt+enter

위에건 잘되고 아래건 오류 완-벽

 

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

<문제점>

1. DIP 위반 

추상화 & 구체화 모두 의존중

우리는 추상화만 의존하고 있는 것을 희망함

2. OCP 위반

할인 정책을 변경하려면, 클라이언트인 OrderServiceImpl을 변경해야 한다.

//OrderServiceImpl.java
public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository = new MemoryMemberRepository();//1
    //private final DiscountPolicy discountPolicy = new FicDiscountPolicy();->
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); //2
    /*생략*/
}

 

<해결>

DiscountPolicy만 일단 해보기

public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private DiscountPolicy discountPolicy;
    //하지만 이것도 NULL이기 때문에 오류가 날 것
    /*생략*/
}

역시 오류가 나니 discountPolicy에 fix던 rate던 골라서 넣어줄 누군가가 필요하다.

 

- 관심사의 분리

"공연 기획자를 만들고, 공연 기획자와 배우의 책임을 확실히 분리하자"

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

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

정말... AppConfig 만들 때 소름끼쳤음... 이게 이렇게 될 수 있다니....

강사님 이거 막 설명하는데 신같고 막

정말 이런거 만들어놓은 사람들 다 대박적 천재 만재임 ㄹㅇ

 

//OrderServiceImpl.java
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;
    }
    /*생략*/
}

//MemberServiceImpl.java
public class MemberServiceImpl implements MemberService{

    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    /*생략*/
}

생성자로 꽂아 넣을 수 있게 고칩니다..!!

private final로 인터페이스 선언하고, 구체화 클래스 받아서 생성하도록 생성자 만들기

AppConfig가 객체를 생성하고, 연결

Impl은 실행에만 집중한다.

=> 관심사의 분리

 

//MemberApp.java
public class MemberApp {
    public static void main(String[] args){
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        /*생략*/
    }
}

//OrderApp.java
public class OrderApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();
        /*생략*/
    }
}

로직으로 테스트하던 코드에도 AppConfig에서 받아온 걸 넣어서 테스트 해줍니다.

ctrl + E ( + 엔터) 최근 파일

 

//MemberServiceTest.java
public class MemberServiceTest {

    MemberService memberService;

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

//OrderServiceTest.java
public class OrderServiceTest {

    MemberService memberService;
    OrderService orderService;

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

jUnit으로 테스트 하던 코드에도 해줍니다. BeforeEach는 테스트 실행하기 전에 실행하는 코드

 

의존관계주입 (DI : Dependency Injection)

 

- AppConfig 리팩터링

현재 AppConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 안보인다.

//AppConfig.java
public class AppConfig {
    //역할이 한눈에 들어온다.
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }


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

    //중복제거. 수정할 때 여기만 수정하면 됨
    public MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    
    public DiscountPolicy discountPolicy(){
        return new FicDiscountPolicy();
    }
}

중복되는거에 대고 ctrl+alt+M : 중복 제거

아 정말 이 부분 너무 감동적이야... 세상에 이렇게 코드가 예쁘게 되다니...

강사님 정말 천재야.... 

근데 내가 이걸 머릿속에 넣고 혼자 만들어 낼 수 있을까?? 이런 생각 못할것같은데 ㅋㅋㅋ

 

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

//AppConfig.java
public class AppConfig {

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

한 줄만 수정하면 할인 정책 바뀜 

구성 영역만 손대면 되고 사용영역은 전혀 손 댈 필요 없다.

이제 DIP와 OCP를 지킬 수 있다!!

 

구성 영역과 사용 영역으로 분리가 되었다.

구성 영역인 AppConfig만 수정하면 정책을 변경할 수 있음

 

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

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

클라이언트 : 구현 객체 생성/연결, 실행

-관심사 분리->

AppConfig : 구현 객체 생성/연결

클라이언트 : 객체 실행

 

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

추상화 인터페이스에 구체화 구현 클래스를 생성하는 부분이 있었으므로,

겉보기엔 추상화 인터페이스에 의존하는 것 같지만, 뿐만 아니라 구현 클래스에도 의존하는 게 되어버렸다.

-구현클래스 파트 제거->

클라이언트 코드는 인터페이스만으로는 아무것도 실행할 수 없다. 

-의존관계 주입->

AppConfig가 대신 객체 인스턴스를 생성해서 의존관계 주입함

 

OCP - 확장에는 열려있으나 변경에는 닫혀 있어야 한다.

애플리케이션을 사용 영역과 구성 영역으로 나눠

구성 영역의 AppConfig만 고치면 확장이 가능해졌다. 

-> 사용 영역의 변경에는 닫혀있다.

 

- IoC, DI, 그리고 컨테이너

제어의 역전 (IoC : Inversion of Control)

직접 관리하는 것이 아니라 외부에서 관리하는 것

ex) 구현 객체가 프로그램의 제어 흐름을 가지는 것이 자연스러운 흐름인데 이제 AppConfig가 제어 흐름을 가져간다.

 

프레임워크 vs라이브러리

프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 프레임워크

내가 작성한 코드가 직접 제어의 흐름을 담당하면 라이브러리

 

의존관계 주입(DI : Dependency Injection)

∨ 정적인 클래스 의존 관계

import만 보고도 의존관계를 판단할 수 있다.

하지만 어떤 구현 객체가 사용될지는 모른다.

ex ) OrderServiceImpl과 MemberRepository, DiscountPolicy의 관계

 

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

실행 시점에 결정되는 동적인 객체

런타임 내에서 구현 객체를 생성하고 클라이언트로 전달

정적인 클래스 의존관계를 변경하지 않고 동적인 객체 인스턴스 의존 관계를 쉽게 변경할 수 있다.

ex) DiscountPolicy와 FixDiscountPolicy, RateDiscountPolicy의 관계

 

IoC컨테이너, DI컨테이너

AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을

IoC컨테이너 또는 DI컨테이너(특성에 맞는 새이름)라고 한다. 

스프링이 DI컨테이너 역할을 한다. 스프링 말고도 많다.

 

- 스프링으로 전환하기

순수한 자바 코드로 DI를 적용했지만, 이젠 스프링을 적용해본다.

//AppConfig.java
@Configuration // 설정 정보에 적음
public class AppConfig {
    //역할이 한눈에 들어온다.
    @Bean //Spring Container에 등록
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public OrderService orderService(){
       return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    //중복제거. 수정할 때 여기만 수정하면 됨
    @Bean
    public MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    @Bean
    public DiscountPolicy discountPolicy(){
        return new FicDiscountPolicy();
    }
}

기본적으로 메서드 이름으로 Bean 이름이 등록된다.

//MemberApp.java
public class MemberApp {
    public static void main(String[] args){
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
    	/*생략*/
    }
}

//OrderApp.java
public class OrderApp {
    public static void main(String[] args) {
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);
    	/*생략*/
    }
}

이렇게 수정을 하고 테스트 코드를 실행시켜 보니

예시 : MemberApp.java

요렇게 뭔가 appConfig와 그 아래 메소드들의 이름이 나오며 잘 실행되는 것을 볼 수 있다.

 

스프링 컨테이너는 @Configuration이 붙은 클래스를 구성 정보로 사용함.

@Bean이 적힌 메소드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록함.

스프링 컨테이너에 등록된 객체 : 스프링 빈

보통 메소드 명이 스프링 빈의 이름이 된다(name = 어쩌구 해서 바꿀 수는 있는데 굳이..?)

이전엔 자바 코드로 일일이 했다면,

이젠 필요할 때마다 쉽게 applicationContext.getBean() 메소드를 이용해 스프링 컨테이너에서 객체를 찾을 수 있다.

 

하지만 아직 이게 왜 좋은지 모르겠다!! 근데 강사님이 다음 강의 때 알려주신다고 하셨다!!