JArchive 프로그래밍 일기

목표

1. 웹 애플리케이션과 싱글톤

2. 싱글톤 패턴 

3. 싱글톤 컨테이너 

4. 싱글톤 방식의 주의점 

5. @Configuration과 싱글톤  (이번 포스팅)

6. @Configuration과 바이트코드 조작의 마법 

5. @Configuration과 싱글톤

아래는 스프링 컨테이너를 만들 때 쓰는 애노테이션 기반 자바 설정 정보 AppConfig.class 클래스 파일이다. 

이상한게 하나 있다. 정말 싱글톤을 보장하고 있을까? @Bean 을 붙여서 빈을 생성하는 코드를 차례로 보자. 

1) memberService 빈을 생성하는 코드를 보자.

-> MemberServiceImpl 을 생성하자 -> memberRepository()를 호출하게 된다.  

memberRepository() 빈을 만드려고 보니 MemoryMemberRepository() 호출하게 된다. 

정리하면,

@Bean memberService 빈 생성 -> memberRepository() 호출 -> MemoryMemberRepository() 호출

2) orderService 빈을 생성하는 코드를 보자.

-> orderServiceImpl 생성하려고 보니 memberRepository() 와 discountPolicy() 를 호출한다. 

memberRepository()를 호출하면  MemoryMemberRepository() 호출된다. 

? 이상한데. MemoryMemberRepository()가 2번 호출되서 객체가 2개 생성된 것 같다! 

정리하면,

@Bean orderService 빈 생성 -> memberRepository() 호출 -> MemoryMemberRepository() 호출

3) 싱글톤이 보장되는지 객체를 출력해서 동일한지 테스트 코드 configurationTest() 를 작성해보자 

MemberServiceImpl 에 생성된 memberRepository가  orderServiceImpl 에 생성된 memberRepository와 같은 객체일까? 

구현체 내부에 생성된 memberRepository 객체를 비교했다. 테스트 결과, 같은 인스턴스가 공유되어 사용됨을 확인했다. 

memberRepository() 생성 호출이 안 되고 있는건 아닐까? 

4) AppConfig.class에 println()출력을 찍어두고 테스트 코드 configurationTest() 를 실행해보자. 

memberRepository 가 생성되는 지점이 어디일까?

AppConfig.class 자바 코드를 보면,  "call AppConfig.memberRepository" 가 3번 출력될 것이다. 

  * memberService 빈 생성할 때 memberRepository가 1번 호출된다.  

  * MemberServiceImple 을 생성할 때 1번 호출된다. 

  * orderService 빈 생성할 때 1번 호출되기 때문에 총 3번 출력 될 것이다. 

테스트를 실행해보니 반전 결과다. 

"call AppConfig.memberRepository" 가 딱 1번만 출력된다. 그러니까 각 스프링빈이 1번만 생성된다. 싱글톤이 보장되고 있었다.

왜그럴까 ? 다음 강의에서 알아보자. 

6. @Configuration과 바이트코드 조작의 마법 

스프링 컨테이너는 싱글톤 레지스트리다. 그러니까 스프링 빈이 싱글톤이 되도록 보장해야 한다. 자바 코드만 봤을 때 분명 3번 호출되어야 맞는데. 어떻게 memberRepository 객체를 1번만 생성한걸까?

그 이유는 스프링은 클래스의 바이트코드 조작 라이브러리를 사용하기 때문이다. 

1) AppConfig.class 가 순수한 클래스로 만든 스프링 빈으로 등록된다? 

AppConfig 도 스프링 빈으로 등록되는데. 생성된 AppConfig 빈의 타입을 getClass() 메서드로 출력해보자. 

순수한 스프링 빈이라면, 내가 만든 AppConfig 클래스는 hello.core.AppConfig 라고 출력되어야 하는데. 

$$EnhancerBySpringCGLIB 라는 이름이 붙어있다. 

내가 만든 클래스가 아닌걸까? 이유를 알아보자. 

2) 스프링이 만든 AppConfig@BySpringCGLIB 클래스가 스프링 빈으로 등록된다!

스프링은 @Configuration이 붙은 클래스를 읽으면, 그 클래스를 그대로 스프링 클래스로 만들지 않는다.

바이트코드 조작 라이브러리를 사용해서 AppConfig.class 클래스를 상속받은 임의의 다른 클래스를 만든다. 그리고 그 클래스를 스프링 빈으로 등록한다. 

클래스 이름에는 BySpringCGLIB 이런 이름이 붙는다. 

그림은 AppConfig.class를 상속받아서 AppConfig@BySpringCGLIB라는 다른 클래스를 만든 것을 표현했다. 

3) AppConfig@CGLIB 클래스가 어떤 역할을 할까? 

 AppConfig@CGLIB 클래스가 스프링 빈의 싱글톤을 보장한다.

(CGLIB 내부 기술을 사용하는데 매우 복잡하다.)

아마도 다음과 같은 로직으로 AppConfig@CGLIB 클래스가 싱글톤을 보장할 것이다. 

1.  AppConfig.class를 쭈욱 읽으면서 @Bean이 붙은 메서드마다 빈을 생성한다

2. 이미 스프링 빈이 존재하면, 스프링 컨테이너에 존재하는 빈을 반환한다. 

3. 컨테이너에 스프링 빈이 없다면, AppConfig.class 의 기존 로직을 읽어서 스프링 빈을 등록하고 반환한다. 

[ 참고 ] 

내가 만든 AppConfig의 타입을 조회했는데. 왜 AppConfig@CGLIB 클래스 타입이 출력되었을까? 

AppConfig@CGLIB 클래스는 AppConfig를 상속받은 자식클래스이기 때문이다. 

빈 조회를 하면서 배운 내용을 떠올려보자. 부모 타입을 조회하면, 자식 타입도 전부 딸려서 조회된다. 

4) 만약, @Configuration 을 적용하지 않고, @Bean 만 붙여도 문제가 없을까? 

애노테이션을 주석처리 하고, 아까 작성한 configurationDeep() 테스트 코드를 실행하여 스프링 빈을 조회해보자.

에러가 나지는 않는다. 하지만 memberRepository 가 3번 호출되어 3개의 객체가 생성된다. 

memberRepository 처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤이 보장되지 않는다. 

5) 정리 

고민할 게 없다. @Configuration 애노테이션이 스프링 빈의 싱글톤을 보장해준다는 점이 핵심이다. 

다음 강의에서는 설정 정보 없이 자동으로 스프링빈을 등록하는 '컴포넌트 스캔'을 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 웹 애플리케이션과 싱글톤  (이번 포스팅)

2. 싱글톤 패턴 

3. 싱글톤 컨테이너 

4. [중요] 싱글톤 방식의 주의점  

5. @Configuration과 싱글톤

6. @Configuration과 바이트코드 조작의 마법 

1. 웹 애플리케이션과 싱글톤  

스프링은 태생이 온라인 서비스 기술을 지원하기 위해 탄생했다. 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 

웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 

고객 요청이 올 때마다 AppConfig가 객체를 새로 만들면? 요청이 올 때마다 인스턴스가 생성되는데.

1000개의 요청이 서버에 들어오면?? 1000개의 인스턴스가 메모리를 차지하게 된다. -> 메모리 낭비! 

해결 방안

객체를 딱 1개만 생성되도록 보장하고 이것을 공유하도록 설계하는 것이다. 

2. 싱글톤 패턴

1) 싱글톤 패턴으로 이 문제를 해결해보자.

싱글톤 패턴은 JVM 안에 클래스의 인스턴스가 딱 1개만 생성되는 방식이다. 

인스턴스를 2개 이상 생성하지 못하도록 막아야 한다! 코드로 확인해보자. 

핵심은 private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막는 것이다.

아래는 싱글톤 패턴 구현 코드다. 

public class SingletonService {

    // 1. 자기 자신을 내부에 private 으로 선언. final 이니까 딱 1번만 생성하고, 2번 생성 불가하게 만든다.
    private static final SingletonService instance = new SingletonService();

    // 2. 인스턴스 조회는 public 으로 열어둠
    public static SingletonService getInstance(){
        return instance;
    }

    // 3. 생성자를 private 으로 생성. 외부에서 new 키워드로 객체 생성 불가하도록 막음
    private SingletonService(){ 
    }

    public void logic(){
        System.out.println("싱글톤 객체 로직 호출");
    }
}

2) 싱글톤을 어떻게 구현할까? : 객체를 미리 생성하는 안전하고 단순한 방법으로 구현해보자. 

1. static 영역에 객체 instance를 미리 1개 생성해서 올려둔다.

    자바가 시작할 때 객체를 하나 생성해서 정적 (클래스) 영역에 상수처럼 가지고 있는 것이다. 이미 1개 생성 끝.

2. 인스턴스 조회할 수 있는 메서드를 public으로 열어뒀다.

    호출할 때 마다 최초에 1개 만들어둔 같은 객체 인스턴스가 반환된다. 

3. 인스턴스 생성은 private 으로 막아뒀다. 외부에서 new 키워드로 객체 생성 불가하게 만들었다. 

    new 키워드로 생성하려는 순간 컴파일 오류남! 세상에서 제일 좋은 오류 컴파일 오류. 

3) 이제 AppConfig를 전부 싱글톤 패턴으로 바꾸면 되겠네요?

-> 스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리한다. 이미 만들어진 객체를 공유한다. 

4) 싱글톤 패턴의 여러 문제점 

객체 마다 싱글톤 패턴 구현하는 코드 자체가 많이 들어간다. 객체 선언, 생성자 등등 구현 코드 필요 

의존관계상 클라이언트가 구체 클래스에 의존한다 -> DIP를 위반한다.

테스트하기 어렵다.

내부 속성을 변경하거나 초기화하기 어렵다.

private 생성자를 쓰니까, 자식 클래스를 만들기 어렵다. 

결론적으로 유연성이 떨어져서 안티패턴으로 불리기도한다. 

3. 싱글톤 컨테이너 

스프링 컨테이너는 싱글톤 패턴의 문제점은 싹 해결하고, 객체 인스턴스를 싱글톤으로 관리한다. 

1) 싱글톤 컨테이너 

스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. 

이렇게 싱글톤 객체를 생성하고 관리하는 컨테이너를 싱글톤 레지스트리라 한다. 

싱글톤 패턴을 위한 지저분한 코드를 안 넣어도 된다. 

private생성자, DIP 위반 등의 단점을 해결하고 싱글톤을 사용할 수 있게 된다. 

2) 싱글톤 객체를 사용하는지 코드로 확인하자. 

MemberService.class 타입 빈을 2개 꺼내자.  참조값이 똑같은지 확인하자. 참조값이 똑같다!

3) 스프링 컨테이너 덕분에 여러개의 요청이 오더라도 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다. 

스프링 컨테이너는 기본 빈 등록 방식이 싱글톤이다. 

하지만 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공하긴 한다. 하지만 99% 경우가 싱글톤을 쓴다.

자세한 내용은 뒤에 빈 스코프에서 배운다. 

4) 스프링 컨테이너의 싱글톤 패턴 확인하는 테스트 코드

[중요] 4. 싱글톤 방식의 주의점

실무에서 아래의 주의점을 안 지켜서 큰 장애가 발생하는 경우가 있다. 

스프링 컨테이너든, 싱글톤 패턴을 구현해서 사용하든
싱글톤 방식을 쓸 때 객체를 무상태로 설계해야 한다. 

1) 무상태(stateless)로 설계해야 한다는 의미가 뭘까? 

* 특정 클라이언트에 의존적인 필드가 있으면 안 된다. 

* 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안 된다. 

* 가급적 읽기만 가능해야 한다. 

* 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다. 

여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 상태유지(stateful)하게 설계하면 안 된다. 

2) 실무에서 자주 발생하는 문제 코드를 알아보자 

StatefulsService 의 order() 메서드 : 사용자가 주문하면 금액을 저장한다.

A사용자는 10000원, B사용자는 20000원 어치를 주문한다고 가정한다.  

사용자 A의 주문금액이 20000원으로 나온다.

StatefulService는 싱글톤 빈이니까. statefulService1 과 statefulService2 는 같은 객체다.

하나의 price 변수에 ThreadA와 ThreadB가 접근해서 값을 변경한 것이다. 

이러면 서비스 망하는거에요. 몇 년에 한 번씩 실무에서 꼭 만나는 상태유지 문제!! 이런 건 잡기도 어렵습니다.

원래는 실무를 반영하려면 멀티스레드 넣고 상속 관계 넣고 하는 복잡한 예제가 더 적절한데, 간단한 예제를 든 것이다. 

결론: 공유 필드는 조심하면서 무상태로 만들자!

3) 무상태 (Stateless)로 바꿔보자! 공유되지 않는 지역변수를 쓰자. 

공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

금액을 리턴값으로 넘기자. 

다음 강의에서는 '@Configuration과 싱글톤'을 배운다. 

프로젝트 레포지토리

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 스프링 컨테이너 생성  

2. 컨테이너에 등록된 모든 빈 조회

3. 스프링 빈 조회 - 기본

4. 스프링 빈 조회 - 동일한  타입이 둘 이상 

5. [ 중요 ] 스프링 빈 조회 - 상속 관계

6. BeanFactory와 ApplicationContext 

7. 다양한 설정 형식 지원 - 자바 코드, XML (이번 포스팅)

8. 스프링 빈 설정 메타 정보 - BeanDefinition

7.  다양한 설정 형식 지원 - 자바 코드, XML

스프링 컨테이너는 다양한 설정 형식을 지원한다. 

자바 코드, XML, Groovy 등등.. 

애노테이션 기반 자바 코드로 설정

지금까지 애노테이션 기반 자바 코드로 설정(팩토리 빈으로 설정)하는 법을 배웠다.

AppConfig라는 팩토리 빈에서 @Bean 애노테이션이 달린 팩토리 메서드를 통해 스프링 빈을 스프링 컨테이너에 등록하는 방식이다. 

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

XML로 설정

이번 시간에는 XML로 설정 해보자. 최근에는 스프링 부트를 많이 사용하면서 이 방식은 드물게 쓰고 있고, 레거시 프로젝트들에서 주로 사용한다. XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있다는 장점이 있다.

1) resource 디렉토리에 appConfig.xml 을 작성한다. 

스프링 빈의 id, class, constructor-arg 등 으로 구성되어 있다. 이 때, class의 전체 경로를 적어줘야 한다.

내용은 자바 코드와 똑같은데 형식이 약간 다를 뿐이다. 

xml 기반 방식은 직접 스프링 빈을 스프링 컨테이너에 등록하는 방식이다. 

2) GenericXmlApplicationContext 에 appConfig.xml 설정 정보를 넘겨서 스프링 컨테이너를 생성한다. 

테스트 코드를 작성해서 memberService 빈을 조회해보자. 

xml 기반으로 설정하는 것은 최근에 잘 안쓰니까 이정도로 마무리하고. 필요하면 레퍼런스 문서를 확인하자. 

8. 스프링 빈 설정 메타 정보 - BeanDefinition

조금 깊이 있는 내용으로 가보자.  

1) 스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까? 그 중심에는 BeanDefinition  이라는 추상화가 있다. 

• 즉, 역할과 구현을 개념적으로 나눈 것이다. 
  • XML 을 읽어서 BeanDefinition을 만들면 된다. 
  • 자바 코드를 읽어서 BeanDefinition을 만들면 된다.
  • 스프링 컨테이너는 자바 코드인지 XML 인지(구현은) 몰라도 된다. 오직 BeanDefinition만(역할만) 알면 된다. 

• BeanDefinition 을 빈 설정 메타정보라 한다. 
• 이 메타정보를 기반으로 인스턴스를 생성한다. 
• BeanDefinition 자체가 인터페이스다. 스프링 컨테이너는 인터페이스만 바라본다.
  • @Bean , <bean> 당 각각 하나씩 메타정보가 생성된다. 이 메타정보를 기반으로 스프링 빈을 생성한다. 

2) 코드 레벨로 들어가보자. 

아유 잘 모르겠다 싶으면 몰라도 된다. 개발에 아~무 지장없다. 

설정 형식 마다 Reader가 있다! 

• ApplicationContext 인터페이스에는 설정 파일을 읽기 위한 여러 구현체들이 있다. 
• 자바 코드 설정을 읽을 Reader == AnnotatedBeanDefinitionReader 가 있다. 얘가 AppConfig.class 파일을 읽어서 빈 메타정보를 생성한다. 
• xml 형식의 설정을 읽을 XmlBeanDefinitionReader 가 있다. 얘가 appConfig.xml을 읽어서 빈 메타정보를 생성한다. 
• 새로운 형식의 설정 정보가 추가되면, 또는 개발자가 새 형식의 설정 정보를 추가하면, XxxBeanDefinitionReader를 만들어서 BeanDefinition을 생성할 수 있다. 

[ 정리 ] 

스프링이 다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용하는 것 정도만 이해하면 된다. 

스프링 관련 오픈 소스를 보다가 BeanDefinition 이 보일 것이다. 이 때 이러한 매커니즘을 떠올리면 된다. 

다음 강의에서는 객체가 JVM안에 딱 하나만 있어야되는 '싱글톤 컨테이너와 싱글톤 방식의 주의점'를 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 스프링 컨테이너 생성  

2. 컨테이너에 등록된 모든 빈 조회

3. 스프링 빈 조회 - 기본

4. 스프링 빈 조회 - 동일한  타입이 둘 이상 (이번 포스팅)

5. [ 중요 ] 스프링 빈 조회 - 상속 관계

6. BeanFactory와 ApplicationContext 

7. 다양한 설정 형식 지원 - 자바 코드, XML

8. 스프링 빈 설정 메타 정보 - BeanDefinition

4. 스프링 빈 조회 - 동일한 타입이 둘 이상 

1) 타입으로 조회 시, 같은 타입이 2개 이상 있으면 중복 오류가 발생한다. 

임시로 MemberRepository 타입 빈이 2개 있는 SameBeanConfig.class 설정 파일을 만들었다. 

여기서 MemberRepository.class 타입 빈을 가져오면? 

아래와 같은 NoUniqueBeanDefinitionException 이 발생한다. 설명이 굉장히 친절하다.

싱글 매칭 빈을 기대했는데, 2개 였다는 내용. 

org.springframework.beans.factory.NoUniqueBeanDefinitionException
: No qualifying bean of type 'hello.corebasic.member.MemberRepository' available
: expected single matching bean but found 2: memberRepository1,memberRepository2

이렇게 특정 에러가 발생하는지 확인하려면 assertThrow와 Exception 클래스명을 써서 확인한다.

2) 타입으로 조회 시, 같은 타입이 2개 이상 있으면 빈 이름을 지정하면 된다!

빈 이름은 중복 불가다. 빈 이름을 안겹치게 지어서 조회하면 된다.

3) 특정 타입을 모두 조회하기

getBeansOfType() 메서드로 Map<이름, 타입> 특정 타입의 모든 빈을 모두 조회할 수 있다. 

나중에 @Autowired같이 자동으로 주입되는 기능을 배울 때 이런식으로 적용이 된다. 

ac.getBeansOfType(MemberRepository.class);

[ 중요 ] 5. 스프링 빈 조회 - 상속 관계 

1) 부모 타입으로 빈을 조회하면, 자식 타입도 함께 조회한다.

스프링 빈 대 원칙 하나는 "스프링 빈 하나 조회하면? 그 빈의 자식을 싹다 조회한다. " 

그래서 모든 자바 객체의 최고 부모인 Object 타입. Object 타입으로 조회하면, 모든 스프링 빈을 조회한다. 

테스트 코드로 확인하자. TestConfig 설정파일을 하나 만들자. DiscountPolicy 이름으로 생성될 빈이 2개다!  반환되는 생성자만 다르다. 

2) 부모 타입을 조회하면, 자식까지 다 딸려서 조회되니까 자식이 둘 이상인 경우 오류가 발생한다. 

이럴 땐 이름을 지어서 구분하면 된다. 

3) 부모 타입을 조회 시, 자식이 둘 이상 있으면, 빈 이름을 지정하면 된다. 

rateDiscountPolicy 특정 빈 이름으로 조회하자. 

4) 특정 하위 타입으로 조회할 수 있다. 

구체적인 타입으로 딱 지정하면 조회할 수 있지만 안 좋은 방법이다. 

5) 부모 타입으로 모두 조회해보자. 

할인 정책 인터페이스를 구현한 구현체 클래스 2개가 조회 된다. 

rateDiscountPolicy, fixDiscountPolicy 자식 타입 스프링 빈 2개가 출력됨을 확인할 수 있다. 

[ 참고 ] 실무에서 테스트 코드를 작성할 때는 이렇게 출력물을 만들면 안된다

지금은 공부용이라서 system.out.print를 하지만, 실무에서 테스트 코드를 작성할 때는 이렇게 출력물을 만들면 안된다. 

테스트 통과/실패 여부만 판단하도록 작성하는게 좋다. 

6) 최고 부모 타입인 Object 로 조회해보자. 

모든 자바 객체의 부모는 Object 라서. 모든 스프링 빈이 조회된다. 

7) 부모 타입으로 조회하면, 자식 타입도 함께 조회한다

실무에서는 ApplicationContext를 통해 getBean() 빈을 조회할 일이 거의 없다. 스프링 컨테이너가 자동으로 의존관계를 주입해주기 때문이다.

굳이 이렇게 배운 이유는, 빈 조회는 스프링의 기본 기능이기도 하고 아주 가끔 순수한 자바 애플리케이션에서 스프링 컨테이너를 생성해서 사용할 일이 있기 때문이다. 
그리고 부모 타입으로 조회 시, 자식 타입 빈까지 조회됨을 알고 있어야 자동 의존관계 주입을 배울 때 잘 사용할 수 있다.

6. BeanFactory 와 ApplicationContext

BeanFactory 와 ApplicationContext에 대해서 알아보자. 아래 계층 구조를 보자.

• 최상위에 있는 인터페이스 BeanFactory 가 있다.
• 최상위에 있는 인터페이스 BeanFactory를 상속받은 인터페이스 ApplicationContext 가 있다. 
• ApplicationContext 는 BeanFactory에 부가 기능을 더한 것이다. 

BeanFactory

• BeanFactory 는 스프링 컨테이너의 최상위 인터페이스다. 
• 스프링 빈을 관리하고 조회하는 역할을 담당한다. 지금까지 빈 조회에 사용한 getBean() 을 BeanFactory이 제공한 것이다. 

ApplicationContext 

• BeanFactory의 모든 기능을 상속 받아서 제공한다. 

BeanFactory와 ApplicationContext의 차이는 뭘까? 

• 애플리케이션을 개발할 때는 빈을 관리하고 조회하는 기능은 물론이고 수 많은 부가기능이 필요하다. 
• ApplicationContext는 아래와 같이 여러 인터페이스를 상속받아서 국제화, 이벤트, 리소스 조회 등의 기능을 제공한다. 
• 우리는 BeanFactory를 직접 사용할 일은 거의 없고, 빈 관리와 부가기능이 포함된 ApplicationContext를 사용한다. 

메시지 소스를 활용한 국제화 기능 

 : 예를 들어 한국에서 접속하면 한국어로, 영어권에서 접속하면 영어로 출력해준다 

환경 변수 

 : 로컬, 개발, 운영 등을 구분해서 환경 변수를 처리 

애플리케이션 이벤트

 : 이벤트를 발행하고 구독하는 모델을 편리하게 지원 

편리한 리소스 조회 

 : 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

BeanFactory 나 ApplicationContext를 스프링 컨테이너라 한다. 

다음 강의에서는 '스프링 컨테이너가 지원하는 자바코드, XML 형식의 설정 정보'를 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 새로운 할인 정책 개발 (이번 포스팅)

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

3. 관심사의 분리 (DI)

4. AppConfig 리팩터링 

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

6. 전체 흐름 정리 

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

8. IoC, DI, 그리고 컨테이너 

9. 스프링으로 전환하기 

1. 새로운 할인 정책 개발

1) 기획자가 새로운 할인 정책을 요청한다. 

기획자: "서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라  정률% 할인으로 변경하고 싶어요."

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

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

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

2) 정률 %할인으로 정책을 만들자. RateDiscountPolicy() 구현 

DiscountPolicy 인터페이스의 구현체 RateDiscountPolicy()를 만든다. 

discount() 메서드를 작성하고 10% 할인 가격을 제대로 계산하는지 JUnit테스트 코드를 작성하자. 

[ JUnit 테스트 생성 Tip ]

RateDiscountPolicy()의 discount()의 테스트 코드를 작성하고 싶다. 

discount() 함수에 커서를 클릭하고, command + Shift + T 를 누르면 "Create New Test" 가 뜬다! 

클릭하면 클래스 이름에 'Test'를 붙여서 자동으로 만들어져 있다. "OK" 를 누르고 JUnit 테스트 파일을 만들자. 

3) 성공 케이스, 실패 케이스를 만들어서 확인한다. 

성공 케이스 : VIP등급이 만원을 주문했을 때, 천원을 할인해주어야 성공하는 케이스 [성공을 기대]

실패 케이스 : BASIC 등급이 만원을 주문했을 때, 천원을 할인해주면 실패하는 케이스 [실패를 기대]

BASIC 등급은 할인이 없다.

걀과 값이 0원인지 확인해야 하는데 일부러 '실패'를 발생시키는 케이스다. 

테스트가 실패하면, JUnit이  Expected 값과 Actual 값을 비교해준다. 

우리는 Actual 이 0원인지 알지만, 일부러 Expected 를 1000이라고 넣었다. 

[ JUnit Assertions Tip ]

static import 해서 assertThat을 간결하게 쓰자. 

// 적용 전 
Assertions.assertThat(discount).isEqualTo(1000);
// 적용 후  
assertThat(discount).isEqualTo(1000);

4) 정률 할인 구현 및 테스트 코드 

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

할인 정책을 적용하면 DIP, OCP를 못 지키는 문제가 발생한다. 

문제를 해결하는 (관심사의 분리, AppConfig 리팩터링, 새로운 구조 적용)과정에서 스프링 컨테이너가 탄생한 이유를 이해하게 된다. 

1) 방금 추가한 정률% 할인 정책을 적용하자

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

[ OK ] 역할과 구현을 충실하게 분리했다.  

[ OK ] 다형성도 활용하고 인터페이스와 구현 객체를 분리했다. 

[ Fail ] OCP, DIP 같은 객체지향 설계 원칙을 준수했..나?

       -> 그렇게 보이지만 사실은 아니다. 주문서비스 클라이언트 OrderServiceImpl 코드를 보자. 

2) 문제점 발견

OrderServiceImpl이 DiscountPolicy 인터페이스 뿐만 아니라 FixDiscountPolicy 구체 클래스도 함께 의존하고 있다. 

단순히 DiscountPolicy 인터페이스만 의존한다고 생각했었는데. 실제로는 구체 클래스도 의존하고 있었다.

-> DIP 위반

"DIP :구현체에 의존하지 말고, 인터페이스에만 의존해야 한다."

[ DIP를 위반하면 어떤 문제가 생기지? ] 

고정 할인 정책을 정률 할인 정책으로 바꿔주세요

-> FixDiscountPolicy 를 RateDiscountPolicy 로 변경. 즉, DIP 위반

-> 클라이언트인 OrderServiceImpl 코드를 고쳐야한다. -> OCP를 위반하게 된다. 

3) 어떻게 문제를 해결할 수 있을까?

원래 의도했던 것처럼 추상에만 의존하도록 변경하자. 클라이언트가 인터페이스에만 의존하도록 하고 싶다. 

이전 코드

변경 코드  "좋아! 인터페이스에만 의존하게 됬어." 깃헙 코드

4) 그런데. 구현체가 없는데 어떻게 코드가 돌아가지? 

주문 생성 테스트를 돌려보면 NPE(NullPointerException) 발생.

5) 해결방안

누군가 OrderServiceImple 클라이언트에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해주어야 한다!

[ 중요 ] 3. 관심사의 분리

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

각각의 인터페이스를 배역(배우 역할)이라 생각하자.

여기서 배역은 누가 선택할까 ? 로미오 역할을 누가할지, 줄리엣 역할을 누가할지 배우들이 정하는 걸까? 

줄리엣 역할을 누가 맡을지는 배우들이 정하지 않는다. 섭외 담당이 따로 있어야 한다. 

그런데 이전 코드는 마치 로미오 역할(인터페이스)을 하는 디카프리오(구현체)가 줄리엣 역할을 할 스칼렛 요한슨(구현체)를 직접 섭외하는 것과 같다. 

배우가 연기만 해야하는데 섭외까지 맡아버리는 다양한 책임을 가지고 있다. 

"구현체가 줄리엣 역할을 할 구현체를 직접 섭외" 한다는 것이 어떤 코드를 말하는거지? 

= OrderServiceImpl(구현체)가 RateDiscountPolicy(구현체)를 직접 선택하고 있다. 

디카프리오 왈 :  "'줄리엣 역할'에는 스칼렛 요한슨이 해주세요."

배우는 배역만 수행하고, 공연 기획자가 나와서 배우를 지정하자!

배우는 배역을 수행하는 것에만 집중해야 한다. 

디카프리오는 김태희가 와도 전지현이 와도 똑같이 공연할 수 있어야한다. 구현체에 상관없이 역할을 수행해야 한다.

배우를 지정하는 책임을 담당하는 별도의 공연 기획자가 나올 시점이다. 

구현 객체를 생성하고 연결하는 공연 기획자 만들기  

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

1) MemberServiceImpl 구현체가 Repository 구현체를 선택하고 있는 문제를 해결하자 

MemberServiceImpl 에서 레포지토리를 MemoryMemberRepository()를 직접 선택하고 있다. 

2) AppConfig가 구현 객체 MemoryMemberRepository 를 생성한다.

그리고 참조를 MemberServiceImpl 생성자에 연결해준다. 

3) MemberServiceImpl 의 생성자 만들기 

MemberServiceImpl의 생성자를 통해 MemberRepository의 구현체를 생성하도록 변경한다. 

이렇게 되면 MemberServiceImpl 구현체가 MemberRepository 인터페이스에만 의존하게 된다.

DIP를 지키게 되었다. Good!

주문 쪽 구현체의 문제도 해결하러가자 

4) OrderServiceImpl 구현체가 Repository 구현체와 DiscountPolicy 구현체를 선택하고 있는 문제를 해결하자 

구현체가 인터페이스에만 의존하도록 바꾸자.

5) AppConfig 가 실제 동작에 필요한 FixDiscountPolicy 구현 객체를 생성한다.

구현체의 참조를 OrderServiceImpl의 생성자에 연결(주입)해준다. 

6) OrderServiceImpl 의 생성자 만들기 

이제 OrderServiceImpl 구현체는 어떤 구현체가 주입되는지 알 필요 없이, 인터페이스에만 의존하며 자신의 역할만 수행하게 된다. 

DIP를 지키게 되었다. Good!

자.. 이제 정리해보자. 

공연 기획자 AppConfig 를 도입해서 DIP를 완성했다 

7) 공연 기획자 AppConfig 역할 : 생성자 주입 

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

2. 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해 주입(연결)한다. 

8) AppConfig 효과 : 의존관계에 대한 고민을 외부에 맡기고 구현체는 실행에만 집중할 수 있게 됬다. 

"구현체는 인터페이스에 맞춰서 기능 실행에만 호출할꺼야"

이제 MemberServiceImpl 구현체는 MemberRepository 인터페이스에만 의존하게 됬다.

OrderServiceImpl 구현체 은 MemberRepository, DiscountPolicy 인터페이스에만 의존하게 됬다. 

AppConfig 를 넣은 클래스 다이어그램과 객체 다이어그램

9) 클래스 다이어그램 : 객체의 생성과 연결은 AppConfig가 담당한다. 

관심사의 분리 : 객체를 생성하고 연결하는 역할과, 실행하는 역할이 명확히 분리된다. DIP 완성

10) 회원 객체 다이어그램 : 클라이언트인 memberServiceImpl 입장에서 바라보자. 

클라이언트 구현체는 어떤 레포지토리 구현체가 들어올지, 어떤 할인 정책 구현체가 생성될지 모른다. 

AppConfig가 구현체 생성 및 연결을 해주기 외부에서 다 해주기 때문이다. 

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

11) AppConfig  넣고 테스트 코드 작성 

테스트 코드에 AppConfig를 생성하고, AppConfig가 인터페이스에 의존관계를 주입한다. 

가입, 주문 생성 모두 테스트 성공이다. 

다음 강의에서는 AppConfig를 리팩토링한다.  

공부 내용 출처 :  스프링 핵심 원리 기본편