[Spring] 스프링 핵심 원리 기본편 (1)

https://start.spring.io/ 에서 시작 파일 생성(dependency X)

자바 21로 하면 오류나니까 17로~!! 

 

setting - gradle - gradle prijects - build and run 인텔리제이로 바꾸기(gradle통해서 실행하면 느림)

 

단축키 확인

setting - keymap

 

실무에서는 그냥 해시맵대신 `concurrentHashMap`을 사용한다 (동시성 이슈)

 

인텔리제이 단축키 command shft enter (문장 자동완성 단축키)

command + option + V (참조변수 자동생성)

option + Enter (임포트 등 오류난 곳으로 이동)

command + shifh + T (테스트 코드 작성하기)

command + E + Enter (이전 창으로 돌아가기)

command + E 히스토리 창

 

구현체가 하나인 경우 주로 클래스 이름에 Impl을 붙임

 

테스트 코드는 성공하는 것도 중요하지만 실패하는 케이스를 확인하는 것이 가장 중요하다(예외 터지는 것 확인하기)

`Assertions`

패키지: org.assertj.core.api.Assertions

 

---

 

 

//    할인정책
//    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
private final DiscountPolicy discountPolicy = new RateDiscountPolicy();

//    위 코드는 클라이언트(해당 클래스)가 구현체에 직접 의존하고 있음(DIP 위반, OCP 위반)
//    할인 코드가 변경되면 실제 코드가 변경됨

 

 

위 코드는 겉보기에만 인터페이스에 의존하고 있는 모양을 할 뿐 실제 생성되는 객체를 직접적으로 선언하고 있으므로 `FixDiscountPolicy`나 `RateDiscountPolicy`를 의존하고 있다.(구체 클래스를 의존하고 있음)

할인 정책을 변경하려면 클라이언트`OrderServiceImpl`의 코드를 고쳐야한다. OCP/DIP를 위반하고 있다.

가솔린 자동차에서 전기 자동차로 바뀌었다고 라이센스를 새로 따야하는 격이다.

 

어떻게 해결할 수 있을까?

🗣️  의존 관계를 느슨하게 하기 위해 생성자에서 매개변수로 `discountPolicy`를 받는 등의 방식으로 밖으로부터 `DiscountPolicy`를 구현한 객체를 받아와서 넣어주는 방식을 이용하면 어떨까용 

 

 

이를 해결하기 위해서는 구현체가 아닌 인터페이스만을 의존해야한다.

 

private DiscountPolicy discountPolicy;

 

 

그런데 이 상태로 실행하면 `NullpointException`이 발생한다. (당연함.. null임)

클라이언트는 인터페이스만으로는 아무것도 실행할 수 없다. (당연함...... 인터페이스임)

그러면 이 문제를 어떻게 해결할까? -> 누군가가 클라이언트인 `OrderServiceImpl`에 `DiscountPolicy`의 구현 객체를 주입해줘야한다!

 

객체 주입만을 담당하는 클래스를 새로 생성한다. -> `AppConfig`

밖에서 객체를 생성해서 주입해준다.

공연에서 배우는 연기만을 담당하고, 배우 섭외는 기획자가 한다.

 

//	public class OrderServiceImpl implements OrderService

	private final MemberRepository memberRepository;

//    할인정책
//    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
//    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
//    위 코드는 클라이언트(해당 클래스)가 구현체에 직접 의존하고 있음(DIP 위반, OCP 위반)
    private DiscountPolicy discountPolicy;

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

 

public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;

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

 

public class AppConfig {

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

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

 

 

`AppConfig`는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.

`AppConfig`에서 객체를 생성하여  클라이언트`OrderServiceImpl`에게 생성자를 통해 주입(Injection)해주기 때문에 클라이언트 클래스는 구체적인 클래스에 대한 정보를 전혀 모르고 있다. 

클라이언트의 입장에서 보면 마치 의존 관계를 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection: 의존관계 주입(의존성 주입))이라고 한다.

 

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

        AppConfig appConfig = new AppConfig();
//        MemberService memberService = new MemberServiceImpl();
        MemberService memberService = appConfig.memberService();
        
        .
        .
        .

 

public class OrderApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();
        .
        .
        .

 

 

Main에서도 `AppConfig`를 생성하여 의존관계를 주입해준다. 둘 다 구체 클래스에 의존하지 않고 인터페이스에만 의존한다. (구체 클래스가 무엇인지 전혀 모르고 있다 -> 수정할 필요가 없다)

 

`@BeforeEach`

테스트 클래스에서 모든 테스트마다 적용해야할 때 해당 메서드(수행되어야 하는 메서드) 위에 붙이는 애너테이션

 

public class MemberServiceTest {

    MemberService memberService;

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

    @Test
    void join() {
    .
    .
    .

 

`@BeforeEach`덕분에 테스트 케이스마다 똑같은 코드를 작성할 필요가 없어짐

 

 

이제 클라이언트 `OrderServiceImpl`은 구체 클래스가 무엇인지 정보를 알 필요 없이 자신의 역할에 충실할 수 있게 되었다.

그런데 `AppConfig`가 어떤 역할을 가지고 있는지 한 눈에 인지하기 어렵다. 그래서 메서드 이름만 봐도 어떤 일을 하는지 알 수 있도록 리팩터링 해주기로 한다.

 

1. 역할과 구현 분리

2. 역할이 잘 드러나도록 작성

3. 중복을 제거함 (new  어쩌구 구구절절 코드를 메서드로 빼낸다)

 

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

    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

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

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

}

 

메서드 이름만 봐도 어떤 일을 하는지 알 수 있게 되었다. (구체 클래스를 생성해서 리턴하는 역할)

멤버 서비스, 리포지토리, 오더서비스, 할인정책이 바뀌어도 해당 클래스만 변경하면 된다.

 

예를 들어 보자. 기획자가 기존의 정액 할인 정책 `FixDiscountPolicy`에서 정률 할인 정책 `RateDiscountPolicy`로 변경하자고 요구했다. 그러면 어느 부분의 코드를 변경해야하겠는가?

 

🗣️ `AppConfig`의 맨 마지막줄인 `discountPolicy()` 메서드의 리턴을 수정합니당

ㄴ ㅇㅇ 맞음 

 

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

 

할인 정책이 단 한 줄의 코드 수정으로 손쉽게 변경되었다.

 

구성 영역은 정책이 변경되면 당연히 변경된다! 구성 역할을 담당하는 `AppConfig`를 공연 기획자라고 생각하자. DI를 잘 설정해주면 클라이언트에 전혀 손대지 않고도 애플리케이션을 수정하고 확장할 수 있다. 사용 영역은 어떤 코드도 변경되지 않았다. 

OCP(확장에는 열려있고 변경에는 닫혀있다)와 DIP(추상화에 의존)가 아주 잘 지켜지고 있다.

 

1. SRP "한 클래스는 하나의 책임만 가져야 한다." 관심사의 분리.

2. OCP "소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다." - 애플리케이션을 사용 영역과 구성 영역으로 나누어 정책이 변경되어 수정이 발생할 경우 구성 영역만 수정하도록 코드를 작성함.

3. DIP "구체 클래스를 의존하지 않고 추상화에 의존해야 한다." - 의존성 주입(DI)는 이 원칙을 따르는 방법 중 하나임.

 

애플리케이션을 하나의 공연으로 생각해보자.

배우는 연기만 하고, 기획자는 기획을 하고, 감독은 감독만 한다. 책임을 분리하는 것이다.

`AppConfig`는 전체 동작 방식을 구성하기 위해 구현 객체를 생성하고 연결하는 책임만을 가지고 있다.

클라이언트 객체는 자신의 역할을 실행하는 것에 집중할 수 있다. 권한이 줄어들어 책임이 명확해졌다.

 

---

 

 

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

이전에는 클라이언트 구현 객체 `OrderServiceImpl`이 스스로 필요한 서버 구현 객체를 생성하고 연결하고 실행했다.(프로그램의 제어 흐름을 스스로 조종함)

`AppConfig`가 등장한 이후로 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 즉, 클라이언트 구현 객체는 스스로 프로그램이 어떻게 흘러가는지 전혀 모르고 있다. 프로그램에 대한 제어 흐름을 `AppConfig`가 가지고 있는 것이다. 

이렇듯 제어의 흐름을 스스로 가지고 있는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)라고 한다.

 

내가 작성한 코드를 대신 제어하고 대신 실행하면 프레임워크(제어의 역전)

내가 작성한 코드를 내가 제어하고 실행하면 라이브러리

 

정적인 클래스 의존 관계: 클래스가 사용하는 import 클래스만 봐도 의존 관계를 쉽게 판단할 수 있다. (애플리케이션을 실행하지 않고도 의존 관계를 분석할 수 있다.) `OrderServiceImpl` 구체 클래스는 `DiscountPolicy` 인터페이스에 의존한다. 

 

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

`OrderServiceImpl` 구체 클래스는 `DiscountPolicy` 인터페이스에 의존한다. 그러나 실제 주입되는 것이 어떤 객체인지는 알 수 없다.(클라이언트가 구현 객체를 전혀 모른다.) 이를 동적인 클래스 의존 관계라고 한다. 애플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성하고 클라이언트에게 전달해주어 의존관계가 실행되는 것을 의존 관계 주입이라고 한다.

 

`AppConfig`처럼 객체를 생성하고 관리하면서 의존 관계를 연결해주는 것을 IoC 컨테이너 또는 DI 컨테이너라고 한다.