[Spring] 토비의 스프링 1장 내용 정리

개방폐쇄원칙(OCP, Open-Closed Principle)

로버트 마틴이 정리한 객체지향 설계 원칙 (SOLID)

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod)

‘Java 프로그래머를 위한 UML 실전에서는 이것만 쓴다’ - 밥 마틴

SRP (The Single Responsibility Principle) : 단일 책임 원칙

OCP (The Open Closed Principle) :  개방 폐쇄 원칙

LSP (The Liskov Subsititution Principle) : 리스코프 치환 원칙

ISP (The Interface Segregation Principle) : 인터페이스 분리 원칙

DIP (The Dependency Inversion Principle) : 의존관계 역전 원칙

스프링은 객체지향적 설계 원칙과 디자인 패턴에 나타난 장점을 자연스럽게 개발자들이 활용할 수 있게 해주는 프레임워크

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

서블릿도 제어의 역전 개념이 적용된 한 예로 볼 수 있다. 서블릿 안에 main() 메소드 없이 컨테이너가 적절한 시점에 서블릿 클래스의 오브젝트를 만들고 그 안의 메소드를 호출

Factory : 디자인패턴의 팩토리 패턴 x. 컴포넌트 역할을 하는 오브젝트들을 설계하는 역할

Bean : 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트 (컴포넌트)

Bean Factory : 빈의 생성과 관계설정 같은 제어를 담당하는  IoC 오브젝트 => Application Context

@Configuration : 빈 팩토리를 위한 오브젝트 설정을 담당하는 클래스 지정

@Bean : 오브젝트(컴포넌트)를 만들어 주는 메소드에 지정

• 빈(bean)

:스프링이 IoC 방식으로 관리하는 오브젝트. managed object(관리되는 오브젝트) 라고도 부름. 모든 오브젝트가 빈은 아님. 스프링이 직접 그 생성과 제어를 담당하는 오브젝트만 해당

• 빈 팩토리(bean factory)

스프링의 IoC를 담당하는 핵심 컨테이너. 빈 등록/생성/조회 등 빈 관리 기능 담당. 보통은 바로 사용하지 않고, 이를 확장한 애플리케이션 컨텍스트를 이용

• 애플리케이션 컨텍스트(application context)

빈 팩토리를 확장한 IoC  컨테이너. 빈 관리 기본 기능은 빈 팩토리와 동일. 이 외에 스프링이 제공하는 각종 부가 서비스를 추가로 제공. 빈 팩토리는 빈의 생성과 제어의 관점에서 이야기, 애플리케이션 컨텍스트는 스프링이 제공하는 애플리케이션 지원 기능을 모두 포함. ApplicationContext 인터페이스는 BeanFactory를 상속.

• 설정정보/설정 메타정보(configuration metadata)

애플리케이션 컨텍스트 또는 빈 팩토리가 IoC를 적용하기 위해 사용하는 메타정보. IoC 컨테이너에 의해 관리되는 애플리케이션 오브젝트를 생성하고 구성할 때 사용. (=청사진(blueprints))

• 컨테이너(Container) / IoC 컨테이너

IoC  방식으로 빈을 관리한다는 의미에서 애플리케이션 컨텍스트나 빈 팩토리를 컨테이너 또는 IoC 컨테이너라고도 한다.

오브젝트의 동일성(identity)과 동등성(equality)

메모리상에 하나의 오브젝트만 존재하고, 두 개의 레퍼런스 변수를 갖고 있는 것을 동일성. 동등성은 메모리 상의 두 개의 서로 다른 오브젝트가 존재하지만 오브젝트의 정보가 동등함을 의미.

equals() 메소드를 오버라이드하지 않으면 Object 의 equals() 메소드를 사용. 이는 동일성을 비교해서 결과를 리턴.

싱글톤 레지스트리로서의 애플리케이션 컨텍스트

서버 애플리케이션은 대용량 트랜잭션에 대해서 오브젝트를 생성하기 때문에 싱글톤으로 관리. 서블릿 또한 대부분 멀티쓰레드 환경에서 싱글톤으로 동작.

싱글톤 패턴 (Singleton Pattern)

1. private 생성자를 갖고 있기 때문에 상속할 수 없음
2. 테스트하기 힘듦
3. 서버환경에서 클래스 로더를 어떻게 구성하고 있느냐에 따라서 싱클톤 크래스임에도 하나 이상의 오브젝트가 만들어질 수 있음
4. 전역 상태를 만들 수 있기 때문에 위험성이 있음

다중 사용자의 요청을 한꺼번에 처리하는 스레드들이 동시에 싱글톤 오브젝트의 인스턴스 변수를 수정하는 것은 매우 위험. 그렇기 때문에 싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우에는 상태정보를 내부에 갖고 있지 않은 무상태(stateless) 방식으로 만들어져야 됨

빈의 스코프

빈이 생성되고, 존재하고, 적용되는 범위.

• 싱글톤 : 스프링 빈의 기본 스코프. 컨테이너 내에 한 개의 오브젝트만 만들어져, 강제로 제거하지 않는 한 스프링 컨테이너가 존재하는 동안 계속 유지
• 프로토타입 : 컨테이너에 빈을 요청할 때마다 매번 새로운 오브젝트 생성.
• 요청 : 웹을 통해 새로운 HTTP 요청이 생길 때마다 생성
• 세션 : 웹의 세션과 유사

의존관계 검색 (dependency lookup)

의존관계를 맺는 방법이 외부로부터의 주입이 아니라 스스로 검색을 이용. 런타임 시 의존관계를 맺을 오브젝트를 결정하는 것과 오브젝트의 생성 작업은 외부 컨테이너에게 IoC로 맡기지만, 이를 가져올 때는 메소드나 생성자를 통한 주입 대신 스스로 컨테이너에게 요청하는 방법을 사용

XML 설정

<beans> -> @Configuration

<bean> -> @Bean

<property> -> 수정 메소드 DI. name, ref 라는 두 개의 애트리뷰트를 갖음. name : 프로퍼티의 이름. ref : 수정자 메소드를 통해 주입할 오브젝트의 빈 이름

<beans>

<bean id=“methodName” class=“a.b.c…BeanClass” />

</beans> 

userDao.setConnectionMaker(connectionMaker()); -> <property name=“connectionMaker” ref=“connectionMaker” />

<bean id=“userDao” class=“io.dorbae.study.spring.dao.UserDao”>

<property name=“connectionMaker” ref=“connectionMaker” />

<bean>

소스코드 다운로드