Spring in Action 요약 1. 스프링 속으로

스프링이 제공하는 거의 모든 기본 사상은 몇 가지 기초적인 개념으로 귀결되며, 이는 스프링의 기본 임무인 '자바개발 간소화'에 모든 초점을 맞춘다. 물론 특정 기능을 간소화 하는 프레임 워크는 많이 존재 한다. 하지만 스프링의 목적은 자 바개발을 폭넓게 간소화 하는 데 있다. 

자바 복잡도 간소화를 위한 스프링의 네 가지 주요 전략

• POJO를 이용한 가볍고(lightweight) 비침투적(non-invasive)인 개발*
• DI와 인터페이스 지향(interface orientation)을 통한 느슨한 결합도(loose coupling)
• 애스펙트와 공통 규약을 통한 선언적(declarative) 프로그래밍
• 애스펙트와 템플릿(template)을 통한 반복적인 코드 제거

* 비침투적 개발은 바탕이 되는 기술을 사용하는 클래스, 인터페이스, API 등을 코드에 직접 나타내지 않는 방법으로 복잡함을 분리할 수 있다. 반면 침투적 개발은 반대의 개념으로 종속객체 주입을 명시적으로 고려하는 방법이다. 복잡함을 가중시킨다.

POJO의 힘

스프링은 가능한 코드의 분산을 막는다. 스프링은 스프링에 특화된 인터페이스의 구현이나 스프링 자체에 의존성이 높은 클래스 확장을 거의 요구하지 않는다. 스프링 기반 애플리케이션의 클래스에는 스플인이 사용된다는 표시도 거의 없다. 최악의 경우 애너테이션이 붙을 뿐 그렇지 않은 경우에는 POJO다.

간단한 형태에도 불구하고 POJO는 매우 강력하다. 스프링이 POJO에 힘을 불어넣는 방법 중 하나는 DI를 이용한 조립이다. DI를 통해 상호 결합도를 낮추는 방법을 알아보자.

종속객체 주입(DI, Dependency Injection)

보통의 경우 두 개 이상의 클래스가 서로 협력하여 비즈니스 로직(logic)을 수행한다. 이때 각 객체는 협력하는 객체에 대한 레퍼런스(reference, 즉 종속객체)를 얻을 책임이 있다. 그 결과 결합도가 높아지고 테스트하기 힘든 코드가 만들어지기 쉽다.

결합도가 높은 코드는 테스트와 재활용이 어렵고 이해하기도 어려우며 유지보수도 어렵다. 반면에 결합이 없는 코드는 아무것도 할 수 없다. 결합은 필요하지만 주의해서 관리해야 한다.

DI를 이용하면 객체는 시스템에서 각 객체를 조율하는 제3자에 의해 생성 시점에 종속객체(dependency)가 부여된다. 따라서 객체는 종속객체를 생성(new 키워드)하거나 얻지 않는다. 즉, 종속객체는 종속객체가 필요한 객체에 주입된다.

public class BraveKnight implements Knight {
	
    private Quest quest;
    
    public BraveKnight(Quest quest) { //interface Quest 주입
    	this.quest = quest;
    }
    
    public void embarkOnQuest() {
    	quest.embark();
    }
}

애플리케이션과 컴포넌트 간의 관계를 정하는 것을 와이어링(wiring)이라고 한다. 스프링에서 컴포넌트를 와이어링 하는 방법은 여러 가지가 있지만 가장 일반적인 방법은 XML을 이용하는 방법이다. 만약 XML 설정 방법이 마음에 들지 않으면 자바 애노테이션을 이용해서 설정할 수 있다.

애스펙트 적용

대체로 각 컴포넌트는 본연의 임무 외에 로깅이나 트랜젝션 관리, 보안 드으이 시스템 서비슫 수행해야 하는 경우가 많다. 이러한 시스템 서비스는 시스템 여러 컴포넌트에 관련되는 경향이 있으므로 횡단 관심사(cross-cuttiong concerns)라고 한다. 이러한 관심사가 여러 컴포넌트에 퍼지게 되면 코드는 여러 컴포넌트에서 중복되고 컴포넌트는 본연의 기능과 관계없는 코드로 지저분해진다.

AOP는 시스템 서비스를 모듈화 해서 컴포넌트에 선언적으로 적용한다. DI가 소프트웨어 컴포넌트의 결합도를 낮춰 준다면, 애스펙트 지향 프로그래밍은 애플리케이션 전체에 걸쳐 사용되는 기능을 재사용할 수 있는 컴포넌트에 담는다. AOP를 이용하면 시스템 서비스에 대해서는 전혀 알지 못하지만. 응집도가 높고 본연의 관심사에 집중하는 컴포넌트를 만든다.

https://stackoverflow.com/questions/23700540/cross-cutting-concern-example

스프링 설정 파일(XML)을 통해 애스펙트를 관리할 수 있다. 

<aop:config>
	<aop:aspect ref="minstrel">
    	<aop:pointcut id="embark" expression="execution(* *.embarkOnQuest(..)"/>
        <aop:before pointcut-ref="embark" method="singBeforeQuest"/>
        <aop:after pointcut-ref="embark" method="singAfterQuest"/>
    </aop:aspect>
</aop:config>

빈을 담는 그릇 컨테이너

스프링 기반 애플리케이션에서는 스프링 컨테이너(container) 안에서 객체가 태어나고, 자라고, 소멸한다. 스프링 컨테이너는 객체를 생성하고, 서로 엮어 주고, 이들의 전체 생명주기(lifecycle)를 관리한다.

https://www.zoltanraffai.com/blog/how-does-spring-work-internally/

스프링 컨테이너는 종속객체 주입을 이용해서 애플리케이션을 구성하는 컴포넌트를 관리하며, 협력 컴포넌트 간 연관관계의 형성도 여기에서 이뤄진다. 이러한 짐을 컨테이너에 덜어 벌니 객체들은 더 명확하고, 이해하기 쉬우며, 재사용을 촉진하고, 단위 테스트가 용이해진다.

스프링 컨테이너는 두 종류가 있는데 DI에 대한 기본적ㅇ니 지원을 제공하는 가장 단순한 컨테이너인 빈팩토리와 프로퍼티 파일에 텍스트 메세지를 읽고 해당 이벤트 리스너에 대한 애플리케이션 이벤트 발행 같은 애플리케이션 프레임워크 서비스를 제공하는 컨테이너다.

또 하나의 컨테이너, 애플리케이션 컨텍스트

스프링으로 작업할 때 빈 팩토리나 애플리케이션 컨텍스트 어느것이든 사용 가능하지만, 빈 팩토리는 애플리케이션 컨텍스트에 비해 제공하는 기능이 빈약하다. 따라서 빈 팩토리 보다는 애플리케이션 컨텍스트를 더 선호하고, 더 많이 사용하게 된다.

빈의 일생

스프링 컨테이너 내에서 빈의 생명주기는 일반적인 자바 애플리케이션에서 보다 조금 더 정교하다. 

https://www.quora.com/What-actually-is-bean-in-Spring-framework

1. 스프링이 빈을 인스턴스화 한다.
2. 스프링이 값과 빈의 레퍼런스를 빈의 프로퍼티에 주입한다.
3. 빈이 BeanNameAware를 구현하면 스프링이 빈의 ID를 setBeanName() 메소드에 넘긴다.
4. 빈이 BeanFactoryAware를 구현하면 setBeanFactory() 메소드를 호출하여 빈 팩토리 자체를 넘긴다.
5. 빈이 ApplicationContextAware를 구현하면 스프링이 setApplicationContext() 메소드를 호출하고 둘러싼 애플리케이션 컨텍스트에 대한 참조를 넘긴다.
6. 빈이 BeanPostProcessor 인터페이스를 구현하면 스프링은 postProcessBeforeInitialization() 메소드를 호출한다.
7. 빈이 InitializingBean 인터페이스를 구현하면 스프링은 afterPropertiesSet() 메소드를 호출한다. 마찬가지로 빈이 init-method와 함께 선언됐으면 지정한 초기화 메소드가 호출된다.
8. 빈이 BeanPostProcessor를 구현하면 스프링은 postProcessAfterInitialization() 메소드를 호출한다.
9. 이 상태가 되면 빈은 애플리케이션에서 사용할 준비가 된 것이며, 애플리케이션 컨텍스트가 소멸될 때가지 애플리케이션 컨텍스트에 남아 있다.
10. 빈이 DisposableBean 인터페이스를 구현하면 스프링은 destroy() 메소드를 호출한다. 마찬가지로 빈이 destory-method와 함께 선언됐으면 지정된 메소드가 호출된다.