스프링 컨터이너는 객체 인스턴스를 싱글톤으로 관리하기 때문에 싱글톤 컨테이너 역할을 한다.

1. 싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

public class SingletonService {
    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingletonService instance = new SingletonService();

    //2. public으로 열어서 객체 인스터스가 필요하면 이 static 메서드를 통해서만 조회하도록
    //허용한다
    public static SingletonService getInstance() {
        return instance;
    }

    //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
    private SingletonService() {}

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

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

2. 싱글톤 패턴의 장점

• 인스턴스가 단 하나이기 때문에 인스턴스를 생성할때 드는 비용이 줄어든다.
  • 메모리 측면의 이점
    • static을 사용하여 별도의 메모리 영역을 받으면서 한번의 new 연산자로 인스턴스를 사용하기 때문에 메모리 낭비를 방지할 수 있다.
  • 속도 측면의 이점
    • 생성된 인스턴스를 사용할 때는 이미 생성된 인스턴스를 활용하여 속도 측면에 이점이 있다.
  • 데이터 공유에 이점
    • 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유할 수 있다.

✅ 싱글톤 패턴의 단점

• 싱글톤 패턴을 구현하는 코드가 추가된다.
• 의존 관계상 클라이언트가 구현체 클래스에 의존하게 된다.
  • → DIP 위반
  • → OCP 위반할 가능성이 높다
• private 생성자로 자식 클래스를 만들기 어렵다.
• 유연성이 떨어져서 안티패턴으로 불리기도 한다.
• 동시성 문제가 발생할 수 있다.

✅ 싱글톤 패턴을 활용하는 사례

싱글톤 패턴은 보통 객체가 리소스를 많이 차지하는 역할을 하는 무거운 클래스일때 사용된다.

대표적으로 데이터베이스 연결 모듈에 많이 사용된다.

데이터 베이스에 접속하는 작업은 무거운 작업에 속하며, 한번만 객체를 생성하고 돌려 쓰면 되지 굳이 여러번 생성할 필요가 없기 때문입니다.

이밖에도 **디스크 연결**, **네트워크 통신**, **DBCP 커넥션 풀**, **스레드 풀**, **캐시**, **로그 기록 객체** 등에 이용된다.

❗ 싱글톤 패턴 설계 시 주의점

싱글톤 방식은 하나의 같은 객체 인스턴스를 공유하기 때문에 항상 상태를 유지(stateful) 하게 설계하면 안된다.

• 특정 클라이언트에 의존적인 필드가 있으면 안된다.
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
• 가급적 읽기만 가능해야 한다.
• 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

package hello.core.singleton;

public class StatefulService {

    private int price; //상태를 유지하는 필드

    public int order(String name, int price){
        System.out.println("name = " + name + "price = "+price);
        this.price = price; //여기가 문제!! -> 상태를 유지하게 설계됨
    }

    public int getPrice() {
        return price;
    }
}

public class StatefulServiceTest {

    @Test
    void statefulServiceSingleton() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

        //ThreadA : A사용자 10000원주문
        statefulService1.order("userA", 10000);
        //ThreadA : B사용자 20000원주문
        statefulService2.order("userB", 20000);

        //ThreadA: 사용자A 주문 금액 조회
        int price = statefulService1.getPrice();
        //ThreadA: 사용자A는 10000원을 기대했지만, 기대와 다르게 20000원 출력
        System.out.println("price = " + price);

        Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }
    static class TestConfig{
        @Bean
        public StatefulService statefulService() {
            return new StatefulService();
        }
    }
}

• 사용자 A가 10000원을 주문하고, 조회하기 전에 사용자 B가 20000원을 주문하면, this.price = price 때문에 A가 주문을 조회 했을때, 10000원이 아닌 20000원이 나온다. → price 필드를 공유하기 때문이다.!

2. 싱글톤 컨테이너란?

싱글톤 패턴의 단점을 보완하기 위해 나온 것이 스프링의 싱글톤 레지스트리이다. 스프링 컨테이너가 싱글톤 레지스트리의 역할을 하여 빈을 싱글톤으로 관리한다.

• 스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리해준다.
• 싱글톤 객체를 생성하고 관리하는 기능을 **싱글톤 레지스트리**라고 한다.
• 싱글톤 레지스트리 덕분에 싱글턴 패턴의 단점을 해결하면서 객체를 싱글톤으로 유지가 가능하다.
• DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.

3. @Configuration

@Configuration 어노테이션를 클래스에 붙이면 @Bean객체들을 싱글톤으로 관리해준다.

@Configuration
  public class AppConfig {
      @Bean
      public MemberService memberService() {
          return new MemberServiceImpl(memberRepository());
      }
      @Bean
      public OrderService orderService() {
          return new OrderServiceImpl(
                  memberRepository(),
                  discountPolicy());
            }
      @Bean
      public MemberRepository memberRepository() {
          return new MemoryMemberRepository();
      }
}

• memberService 를 보면 memberRepository 를 호출한다.
  • → MemoryMemberRepository 를 생성 호출한다.
• orderService 를 보면 memberRepository를 호출한다.
  • → MemoryMemberRepository 를 생성 호출한다.

이렇게 되면, 각각 다른 2개의 MemoryMemberRepository 가 생성되면서 싱글톤이 깨지는 것처럼 보인다.

하지만, 테스트를 통해 확인 해본 결과는 같은 인스턴스를 가리킨다.

이렇게 되는 이유는 @Configuration과 바이트코드 조작에 비밀이 있다.

⁉ @Configuration과 바이트코드 조작

@Test
    void configurationDeep() {
        // 이 과정에서 Appconfig 도 스프링 빈으로 등록된다
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        // Appconfig 조회
        AppConfig bean = ac.getBean(AppConfig.class);

        // 클래스 타입 출력
        System.out.println("bean = " + bean.getClass());

    }
// 출력 - > bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$f1bf9c1

예상한 결과는 class hello.core.Appconfig 였지만, 클래스명에 xxxCGLIB가 붙으면서 상당히 복잡해 진것을 볼 수 있다.

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

이처럼 AppConfig가 있는데 CGLIB라는 바이트 코드 조작 라이브러리를 가지고 상속받아서 아예 다른 클래스를 만들어 버린것이다.

그리고 그 조작한 클래스를 스프링 빈으로 등록한다!

• 만약 스프링 컨테이너에 해당 객체가 등록이 되어 있다면 → 스프링 컨테이너에서 찾아서 반환
• 스프링 컨테이너에 해당 객체가 등록이 안되어 있다면 → 클래스를 조작해서 스프링 컨테이너에 등록한다.

**스프링 컨테이너** 는 자바 객체의 생명 주기를 관리하며, 생성된 자바 객체들에게 추가적인 기능을 제공하는 역할이다. 스프링에서는 자바 객체를 **빈(Bean)**이라고 부르며, **IoC**, **DI**와 같은 SOLID원칙을 지키기 위한 기술이 **스프링 컨테이너**에 적용되어 있다.

1. 스프링 컨테이너란?

기존 객체의 생성주기는 개발자가 new 연산자, 인터페이스 호출, 팩토리 호출 방식으로 객체를 생성하고 소멸해야 한다.

하지만 스프링에서는 스프링 컨테이너가 이 역할을 대신 해준다. 즉 IoC(제어 흐름을 외부에서 관리한다.)가 적용되어 있다. 또한 객체(빈)간의 의존 관계를 스프링 컨테이너가 런타임(실행중)에 알아서 만들어 준다.

2. 스프링 컨테이너의 생성 과정

//스프링 컨테이너 생성
ApplicationContext applicationContext =
new AnnotationConfigApplicationContext(AppConfig.class);

• ApplicationContext를 스프링 컨테이너라 한다.
• ApplicationContext는 인터페이스 이다.
• AnnotationConfigApplicationContext는 ApplicationContext 인터페이스의 구현체이다.
• 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다.

✔ [생성] 스프링 컨테이너 생성

//스프링 컨테이너 생성
ApplicationContext applicationContext =
new AnnotationConfigApplicationContext(AppConfig.class);

• 스프링 컨테이너를 생성할 때는 구성 정보를 지정해 주어야한다.
• 위 코드에서는 AppConfig.class가 구성 정보이다.

✔ [등록] 스프링 빈 등록

스프링 컨테이너는 구성정보(config.class 정보)를 사용해서 스프링 빈을 등록한다.

스프링 빈 저장소에 key(빈 이름) → value(빈 객체) 로 map과 같은 형태로 저장되어 있다고 생각하면 편하다.

스프링 빈 규칙

• 빈 이름은 메서드 이름을 사용한다.
• 빈 이름을 직접 부여할 수 있다.
• 빈 이름은 항상 다른 이름을 부여 해야 한다.

✔ 스프링 빈 의존 관계 설정

• 스프링 컨테이너는 구성 정보를 참고해서 의존관계를 주입한다.
• 단순히 자바 코드를 호출하는 것과 차이가 있다.(싱글톤 컨테이너)
• 스프링 빈을 등록하는 순간, 의존 관계 주입도 한번에 처리된다.

✔ [조회] 컨테이너에 등록된 빈 조회

public class ApplicationContextInfoTest {
         //스프링 컨테이너 생성
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력하기")
    void findAllBean() {
        String[] beanNames = ac.getBeanDefinitionNames();//스프링에 등록된 모든 빈 이름을 조회
        for (String beanName : beanNames ) {
            Object bean = ac.getBean(beanName);//빈 이름으로 빈 객체(인스턴스)를 조회
            System.out.println("name = " + beanName + "Object =" + bean);
        }
    }

    @Test
    @DisplayName("직접 등록한 빈 출력하기")
    void findApplicationBean() {
        String[] beanNames = ac.getBeanDefinitionNames();
        for (String beanName: beanNames ) {

                        //getBeanDefinition: Bean에 대한 meta data 정보들을 반환한다
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanName);

                         //사용자가 정의한 빈일 경우에만 if문 수행
            //Role ROLE_APPLICATION: 직접 등록한 애플리케이션 빈
            //Role ROLE_INFRASTRUCTURE: 스프링이 내부에서 사용하는 빈
            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION){ 
                Object bean = ac.getBean(beanName);
                System.out.println("name = " + beanDefinitionName + "Object =" + bean);
            }

        }
    }

}

주요 메서드

• ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름을 조회한다.
• ac.getBean() : 빈 이름으로 빈 객체를 조회한다.
• ac.getBeanDefinition() : Bean에 대한 meta data 정보를 반환한다.
• ac.getBeansOfType() : 사용하면 해당 타입의 모든 빈을 조회할 수 있다. (return : map)

빈 조회 규칙

• 부모 타입으로 조회하면 자식 타입도 함께 조회한다.
  • → 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회한다.

💡 실제로 ApplictionContext에서 직접 getBean()을 쓸 일은 별로 없다. → 주로 스프링이 자동으로 의존관계를 주입해주기 때문 단, 자동 주입에 대해 쉽게 이해하기 위해서는 한번쯤은 이해해야하며, 순수 java에서 spring container를 사용해야할때 사용된다.

3. 스프링 컨테이너 종류

스프링 컨테이너에는 BeanFactory와 ApplicationContext가 있습니다.

1. BeanFactory

• 스프링 컨테이너의 최상위 인터페이스
• 스프링 빈을 관리하고 조회하는 역할을 담당한다.
• getBean() 등의 빈 객체와 관련된 메서드를 해당 인터페이스가 제공한다.

2. ApplicationContext

• BeanFactory 기능을 모두 상속받아서 제공한다.
• BeanFactory의 모든 기능을 포함하는 것은 물론이고 아래 추가 기능들을 제공한다.
• 대표적인 추가기능
  • **Environment : 프로파일(Profile)을 설정하고 어떤 것을 사용할지 선택할 수 있게 해주며, 소스 설정 및 프로퍼티 값을 가져오게 해준다.
  • **MessageSource : 메세지 설정 파일을 모아서 각 국가마다 로컬라이징을 함으로써 각 지역에 맞춤 메시지를 제공(메시지에 대한 국제화(i18n)을 제공하는 인터페이스)

💡 BeanFacory는 빈 관리 기능을 제공한다. ApplicationConext는 빈 관리기능 (BeanFactory)와 더불어 편리한 부가기능을 더 제공한다. → BeanFactory를 직접 사용할 일은 거의 없다. 대부분 부가기능이 포함된 ApplicationContext를 사용한다. → 둘 다 스프링 컨테이너라고 부른다.

Spring의 큰 장점 중 하나는 자바의 장점인 OOP(객체지향프로그래밍)을 할 수 있다는 것이다.

1️⃣ 다형성(Polymorphism)

다형성이란 역할과 구현의 분리를 말한다.

다형성을 고려하고 객체를 설계할 때 Interface(역할)을 먼저 부여한 후 그 역할을 수행하는 **Implementation(구현체)**를 만들게 된다.

이러한 방법으로 설계를 한다면 클라이언트는 **Interface(인터페이스)**을 사용하기 때문에 인터페이스를 구현한 **Implementation(구현체)** 내부에 대해서 알 필요가 없다. 또한 구현체를 변경할때 클라이언트의 코드는 전혀 영향을 받지 않는다는 장점이 있다.

public class MemberService {
    // private MemberRepository memberRepository = new MemoryMemberRepository();
    private MemberRepository memberRepository = new JdbcMemberRepository();
}

MemoryMemberRepository와 JdbcMemberRepository는 MemberRepository인터페이스를 구현한 구현체이다. 현재는 JdbcMemberRepository 구현체를 사용하고 있다.

이처럼 다형성을 활용하면 실행시점에 객체 인스턴스를 유연하게 바꿀 수 있고, 클라이언트 코드 변경 없이 서버의 구현 기능을 변경할 수 있기 때문에 확장에 유용하다.

하지만 순수한 자바로는 SOLID 원칙을 지키지 못한다.

2️⃣ SOLID 원칙

SRP OCP LSP ISP DIP 로 OOP 할때 지켜야하는 원칙이다.

SRP(Single Reponsibility prinicipal)

단일 책임 원칙 : 한 클래스는 하나의 책임만 져야 한다.

하나의 책임이란 말이 모호하지만, 변경을 기준으로한다.

어떤 기능이 외부 클래스나 라이브러리에 종속적이게 된다면 라이브러리나 외부 클래스가 변경이 된다면 기능에 영향이 있다. 이를 최소화 할 수 있도록 클래스를 설계하는 것이 원칙이다.

OCP (Open Closed Principal)

개방 폐쇄 원칙 : 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다.

public class MemberService {
    // private MemberRepository memberRepository = new MemoryMemberRepository();
    private MemberRepository memberRepository = new JdbcMemberRepository();
}

이처럼 MemberService (클라이언트) 에서 MemoryMemberRepository(구현체) 에서 확장된 기능이 구현되어 있는 JdbcMemberRepository(구현체)로 교체를 했어도 결국 클라이언트에서 구현체를 바꿔야하기 때문에 순수 자바 만으로 OCP를 순전히 지키기 힘들다.

LSP (Liskov Substitution Principal)

리스코프 치환 원칙 : 다형성에서 하위 클래스는 인터페이스의 규약을 다 지켜야한다.

같은 인터페이스나 클래스를 상속받는다면 구현체들은 인터페이스 및 클래스의 규칙을 지켜서 개발해야한다.

ISP (Interface Segregation Principal)

인터페이스 분리 원칙 : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나 보다 낫다.

예를 들어 Car라는 인터페이스를 운전 인터페이스, 정비 인터페이스로 분리한다.

그러면 클라이언트도 운전 클라이언트, 정비 클라이언트로 분리가 되는데 이러면 정비 클라이언트가 변해도 운전 클라이언트에 영향을 주지 않는다.

즉 인터페이스가 명확해지고, 대체 가능성이 높아진다.

DIP(Dependency Inversion Principal)

의존관계 역전 원칙 : 구현 클래스에 의존하지 않고 인터페이스를 의존하라

만약 구현 클래스를 의존하면 **OCP를 지키기 어려울 뿐만 아니라 **변경이 아주 어려워진다. 즉 클라이언트가 구현 클래스는 모르고 인터페이스를 의존하여 사용하라는 뜻이다.

public class MemberService {
    private MemberRepository memberRepository = new MemoryMemberRepository();
}

여기서 **MemberService(클라이언트)**는 MemberRopository (인터페이스)를 의존하고 있지만 이를 구현한 MemoryMemberRepository(구현체)도 의존하고 있다

3️⃣ Spring 의 해결 방법

스프링은 순수 자바의 한계점(OCP,DIP) 들을 다음 기술로 해결해준다.

• DI(Dependency Injection)
• DI Container

이 기술들로 클라이언트 코드의 변경없이 기능을 확장할 수 있다.

IoC(Inversion of Control)

IoC란 Inversion of Control의 줄임말이며, 제어의 역전이라고 한다.

메소드나 객체의 호출작업을 개발자가 결정하는 것이 아니라, 외부에서 결정되는 것을 의미한다.

public class MemberService {
    // 구현체 의존 DIP 위반
    // 구현체 변경을 하려면 클라이언트에서 수정해야 하므로 OCP 위반
    private MemberRepository memberRepository = new JdbcMemberRepository();
    // private MemberRepository memberRepository = new MemoryMemberRepository();
}

위 코드는 클라이언트가 필요한 서버 구현 객체를 스스로 생성하고, 연결하고, 실행하였다. 즉 구현 객체가 프로그램의 제어 흐름을 스스로 조종하였다.

여기에 IoC를 적용한다면

public class AppConfig {

    public MemberRepository memberRepository() {
        return new JdbcMemberRepository();
    }
    public MemberService memberService() {
        return new MemberService(memberRepository());
    }
}

AppConfig class를 만들어서 JdbcMemberRepository(구현체)를 대신 생성해서 MemberService(클라이언트)에 주입할 수 있도록 만들어주었다.

즉, AppConfig class는 프로그램의 제어를 담당하는 클래스이다.

DI (Dependency Injection)

의존성 주입이라는 뜻으로, IOC를 구현하기 위해 사용하는 기법 중 하나이다.

public class MemberService {
    // 클라이언트는 인터페이스에만 의존한다. DIP 지킴
    // 구현체를 변경해도 클라이언트의 변화는 없다. OCP 지킴
    private final MemberRepository memberRepository;

        //외부에서 의존하는 객체를 주입받는다.        
        public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    public String save(String username) {
        return memberRepository.save(username);
    }
}

이와 같이 의존하는 객체를 외부에서 주입받도록 설계하는 기술이 DI 이다.

IoC container

스프링 프레임워크도 객체에 대한 생성 및 생명주기를 관리할 수 있는 기능을 제공하고 있다. 즉, IoC 컨테이너 기능을 제공한다.

인스턴스 생성부터 소멸까지의 인스턴스 생명주기 관리를 개발자가 아닌 컨테이너가 대신 해줍니다.

객체관리 주체가 프레임워크(Container)가 되기 때문에 개발자는 로직에 집중할 수 있는 장점이 있습니다.

• IoC 컨테이너는 객체의 생성을 책임지고, 의존성을 관리한다.
• POJO의 생성, 초기화, 서비스, 소멸에 대한 권한을 가진다.
• 객체 생성 코드가 없으므로 TDD가 용이하다.

💡 **“컨테이너”**란? 
보통 객체의 생명주기를 관리, 생성된 인스턴스들에게 추가적인 기능을 제공하도록 하는 역할

💡 **“POJO”** 란?
주로 **특정 자바 모델이나 기능, 프레임워크를 따르지 않는 Java Object를 지칭**한다.
Java Bean 객체가 대표적이다.