스프링 볶음밥 - 1장 - 4,5,6

# 이 게시글은 "토비의 스프링" 책을 보고 정리를 위해 기록해둔 게시글입니다.

+ 김영한의 스프링 핵심 기본원리 강의도 참고했습니다.

 

[이전글]

볶음밥 1장 - 1,2,3: 자바빈, 디자인 패턴(템플릿 메소드, 팩토리 메소드, 전략 패턴), 관심사의 분리, SOLID 및 객체지향 약간

 

[1-4] 제어의 역전(IoC)

팩토리: 객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 반환하는 역할을 수행하는 오브젝트.

( != 추상 팩토리 패턴, 팩토리 메소드 패턴)

- 오브젝트를 생성하는 쪽과 생성된 오브젝트를 사용하는 쪽의 역할 및 책임을 분리하려는 목적으로 사용한다.

- 애플리케이션 내 오브젝트를 구성하고, 관계를 정의하는 책임을 담당한다. 구조 및 관계를 정의하는 설계도 역할.

-애플리케이션의 컴포넌트 역할을 하는 오브젝트와 애플리케이션의 구조를 결정하는 오브젝트를 분리할 수 있다.

- 확장에는 자유롭고 변경에는 닫혀있다. (OCP)

 

제어의 역전(Inversion of Control, IoC): 프로그램의 제어 흐름 구조가 뒤바뀌는 것.

기존 방식: 모든 클래스가 자신이 사용할 클래스를 직접(능동적으로) 결정한다. 언제 어디서 만들지를 스스로 정한다.

IoC 적용 후: 자신이 사용할 클래스를 스스로 선택하지 않는다. 모든 제어 권한을 자신이 아닌 제 3자에게 위임한다. (어디서, 어떻게 만들어졌는지는 알 필요가 없다)

- IoC를 위해서는 프레임워크 또는 컨테이너와 같이 애플리케이션 컴포넌트의 생성과 관계설정, 사용, 생명주기 관리 등을 전담하는 무언가가 필요하다. 이를 스프링에서는 스프링 컨테이너가 맡아서 담당.

** IoC는 프레임워크만의 기술이 아니고 프레임워크가 꼭 필요한 개념도 아니다.

 

[프레임워크 vs 라이브러리]

핵심: 주도권을 누가 가지고 있는가?

라이브러리: 주도권이 나에게 있다. 라이브러리는 개발자가 애플리케이션 흐름을 직접 제어한다. 필요한 기능이 있을때 능동적으로 라이브러리를 가져와 사용하는 것이다.

프레임워크: 주도권이 나에게 없다. 개발자는 프레임워크에 맞는 클래스를 등록해두고, 프레임워크가 흐름을 주도하면서 작성된 코드를 가져다 사용하는 것이다. 다시말해 제어의 역전 개념이 적용된 것.

 

 

[1-5] 스프링의 IoC

스프링의 핵심 기능 = 애플리케이션 컨텍스트(=빈 팩토리)를 통한 IoC 지원

빈: 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트, 애플리케이션 컴포넌트.

-> 스프링 빈: 스프링 컨테이너가 생성과 관계 설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트를 가리키는 말.

 

스프링에서 빈의 생성과 관계 설정같은 제어를 담당하는 IoC 오브젝트를 빈 팩토리(Bean Factory)라고 부른다. 하지만 주로 빈 팩토리를 확장한 애플리케이션 컨텍스트(Application Context)를 사용한다.

- 애플리케이션 컨텍스트는 빈 팩토리를 확장한 것으로, 사실상 두가지는 동일하다고 생각하면 된다.

- 빈 팩토리는 빈 생성 및 관계를 설정하는 IoC의 기본 기능의 의미를 부각할 때 사용한다. 이외 상황에서는 일반적으로 애플리케이션 컨텍스트 사용.

- 애플리케이션 컨텍스트는 별도의 설정정보를 참고해서 빈의 생성, 관계설정 등의 제어 작업을 총괄하는 범용적인 엔진과도 같다.

스프링 핵심 기본원리 강의 pdf중

오브젝트 설정을 담당하는 클래스에는 @Configuration 애노테이션을 붙인다.

오브젝트 생성을 담당하는 메소드에는 @Bean 애노테이션을 붙인다.

@Configuration(애노테이션)이 붙은 애플리케이션 컨텍스트를 사용하려고 하면 ApplicationContext의 구현체 중 하나인 AnnotationConfigApplicationContext를 사용하면 된다.

 

ApplicationContext ac = new AnnotationConfigApplicationContext(DaoFactory.class);
UserDao dao = ac.getBean("userDao", UserDao.class);

 

1. 애플리케이션 컨텍스트(=스프링 컨테이너)는 @Configuration이 붙은 IoC 설정정보들을 등록한다.

스프링 핵심 기본원리 강의 pdf중

2. @Bean이 붙은 메소드의 이름을 가져와 스프링 컨테이너에 등록한다. 등록된 스프링 빈은 설정정보 파일에 의해 의존관계가 맺어진다. 이후 클라이언트가 애플리케이션 컨텍스트의 getBean() 메소드를 호출하면 빈 목록에서 해당 이름의 빈을 찾아 빈을 생성하는 메소드를 호출, 오브젝트를 생성한 이후 클라이언트에게 리턴해준다.

스프링 핵심 기본원리 강의 pdf중

- 클라이언트는 어떤 팩토리 클래스가 사용되는지를 알 필요가 없다.

- 애플리케이션 컨텍스트는 단순히 오브젝트 생성 및 관리만 하는게 아니라 생성 방식, 시점과 전략의 변화, 후처리, 인터셉트, 외부 연동 등 다양한 부가기능을 제공한다.

 

[스프링 IoC에서의 용어]

(스프링) 빈: 스프링이 IoC 방식으로 관리하는 오브젝트. 모든 오브젝트가 전부 다 빈은 아니다. 스프링이 직접 생성과 제어를 담당하는 오브젝트만이 빈이라고 불린다. = 스프링 컨테이너에 등록된 객체

빈 팩토리: 스프링의 IoC를 담당하는 핵심 컨테이너. 빈 등록, 생성, 조회, 관리 기능을 담당한다. 일반적으로는 빈 팩토리를 확장한 애플리케이션 컨텍스트를 사용한다.

애플리케이션 컨텍스트: 빈 팩토리를 확장한 IoC 컨테이너. 빈 팩토리 기능 + 스프링이 제공하는 각종 부가기능.

설정정보/메타정보: 애플리케이션 컨텍스트가 IoC를 적요하기 위해 사용하는 메타정보, configuration.

(IoC, 스프링) 컨테이너: IoC 방식으로 빈을 관리한다는 의미에서 빈 팩토리나 애플리케이션 컨텍스트를 컨테이너라고 부른다. 컨테이너라는 말 자체가 IoC를 내포하고 있음. 또한 애플리케이션 컨텍스트를 통틀어서 스프링 컨테이너라고 부른다. 

스프링 프레임워크: 애플리케이션 컨텍스트를 포함해서 스프링이 제공하는 모든 기능을 통틀어 말할 때 주로 사용. 

 

 

[1-6] 싱글톤 레지스트리와 오브젝트 스코프

[동일성 vs 동등성]

동일성(identical): 두개의 오브젝트가 완전히 동일함. (== 비교)

동등성(equivalent): 동일한 정보를 담고 있음 (equals() 비교)

- 동일한 오브젝트는 동등하다. 하지만 동등한 오브젝트가 동일하지는 않다.

- 두 오브젝트가 서로 동일하다면 사실 오브젝트는 하나만 존재하고 있는것이다. 같은 주소값을 참조하고 있는 것.

- equals() 메소드를 오버라이딩 하지 않았다면 Object 클래스의 equals() 메소드를 사용한다. 기본 메소드는 두 오브젝트의 참조값을 비교함(동일성 비교를 한다)

 

애플리케이션 컨텍스트는 기본적으로 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이다.

Why 싱글톤?: 스프링은 서버 환경에서 주로 사용되기 때문

- 대규모 서버 환경은 동시에 수많은 요청을 처리할 수 있어야 함. 싱글톤이 아닌 상황이라면 요청이 올 때 마다 새로 오브젝트를 생성해야 한다. -> 너무 많은 부하 발생, 감당 못해! --> 오브젝트를 하나만 만들어놓고 공유해서 사용하자!!

- 서블릿은 멀티스레드 환경에서 싱글톤으로 동작한다. 서블릿 클래스당 하나의 오브젝트만 만들어두고 여러 스레드에서 하나의 오브젝트를 공유해 사용한다.

 

[싱글톤 패턴]

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

- private 생성자를 사용해 외부에서 new 키워드로 인스턴스를 생성하지 못하게 막아야 한다.

<단점>

1. private 생성자를 갖고있기 때문에 상속할 수 없음 (자바의 public/protected/private 상속 참고)

2. 내부 속성을 변경하거나 초기화하기 어려움 = 유연성이 떨어짐

3. 테스트 하기 어려움 (Mock 객체 등으로 대체하기가 어렵다)

-> 자바 코드로 직접 싱글톤 패턴을 만드는건 객체지향을 따르기 어려운 총체적 난국, 안티패턴이다.

<유의점>

stateless(무상태) 하도록 설계해야 한다.

- 멀티스레드 환경에서 여러 스레드가 하나를 공유해서 사용하기 때문에 특정 클라이언트에 의존적인 필드가 있으면 안된다.

- 특정 클라이언트가 값을 변경할 수 있는 인스턴스 변수가 존재하면 안된다. 대참사가 발생한다. 개별적으로 바뀌는 정보는 로컬 변수 혹은 파라미터를 통해 넘겨줘야 한다.

- 읽기 전용, 자신이 사용하는 또다른 싱글톤 빈을 저장하는 경우에는 인스턴스 변수를 사용할 수 있다. 읽기 전용인 경우에는 static, static final을 붙여주자.

 

스프링 컨테이너는 싱글톤을 생성, 관리 및 공급하는 싱글톤 관리 컨테이너다.

- private 생성자가 아닌 일반적인 클래스라도 스프링 컨테이너에게 제어권을 위임함으로써 싱글톤 방식으로 사용할 수 있다. (= 싱글톤 패턴이 적용되지 않은 클래스도 싱글톤 클래스로 사용할 수 있게 해준다)

-> 스프링 컨테이너가 싱글톤을 대신 관리함으로써 객체지향적인 설계와 디자인 패턴을 제약 없이 적용할 수 있다

 

스프링 빈이 생성되고, 존재하고, 적용되는 범위를 빈의 스코프(scope)라고 부른다.

- 기본적으로 싱글톤 스코프가 적용된다. 컨테이너 내에 하나의 오브젝트가 생성되어서, 강제로 제거되거나 스프링 컨테이너가 종료되기 전까지 계속 유지된다.

- 필요 시 싱글톤 이외의 스코프(프로토타입 스코프, 요청 스코프, 세션 스코프)를 사용할 수도 있다.

 

 

 

 

 

내용이 점점 어려워진다... 역시 만만치 않은 책이야..