y-log

컨테이너 초기화와 종료

스프링 컨테이너는 초기화와 종료라는 라이프 사이클을 갖는다.

• 컨텍스트 객체가 생성되는 시점에 컨테이너를 초기화함
• 스프링 컨테이너는 설정 클래스에서 정보를 읽어와 알맞은 Bean 객체를 생성하고, 각 Bean을 연결(의존 주입)하는 작업 수행
• 초기화가 끝난 후 컨테이너를 사용 가능(getBean()등의 작업으로 Bean 객체를 구하는 행위 등)
• 컨테이너 사용이 끝나면 컨테이너를 close() 매서드를 사용해 종료, Bean 객체의 소멸

 기본적으로 Spring의 ApplicationContext 구현은 초기화 프로세스에서 모든 싱글톤 빈을 생성 및 설정

> 따라서 Bean에 문제가 있을 경우 초기화 단계에서 알 수 있다는 장점이 존재

// 1. 컨테이너 초기화
AnnotationConfigApplicationiContext ctx = 
        new AnnotationConfigContext(AppContext.class);

// 2. 컨테이너에서 빈 객체를 구해서 사용
Greeter g = ctx.getBean("greeter", Greeter.class);
String msg = g.greet("스프링");
System.out.println(msg);

// 3. 컨테이너 종료
ctx.close();

1. AnnotationConfigApplicationiContext의 생성자를 이용해서 context 객체를 생성한다.
   이 시점에서 스프링 컨테이너 초기화가 진행되고, 이 스프링 컨테이너는 설정 클래스에서 정보를 읽어와 알맞은 빈 객체를 생성하고 각 빈을 연결(의존주입)하는 작업을 수행한다.
   
   
2. (위에서 초기화되어 사용가능한 컨테이너) getBean()과 같은 메서드를 이용해서 컨테이너에 보관된 빈 객체를 구한다.
   
   
3. 컨테이너 사용을 종료할 때 사용하는 메서드이다. AbstractApplicationContext 클래스에 정의되어 있다.
   AnnotationConfigApplicationiContext가 AbstractApplicationContext를 상속 받기 때문에 close() 사용이 가능하다.

컨테이너 초기화 -> 빈 객체의 생성, 의존 주입, 초기화
컨테이너 종료 -> 빈 객체의 소멸

스프링 빈 객체의 라이프 사이클

객체생성 - 의존설정 - 초기화 - 소멸

스프링 컨테이너는 빈 객체의 라이프 사이클을 관리한다.

1. 빈 객체의 초기화와 소멸 : 스프링 인터페이스

• org.springframework.beans.factory.InitializingBean
• org.springframework.beans.factory.DisposableBean

빈 객체를 생성한 뒤, 초기화 과정이 필요하면

InitializingBean 인터페이스를 상속하고 afterPropertiesSet()메서드를 구현하면 된다.

빈 객체의 소멸 과정이 필요하면 DisposableBean 인터페이스를 상속하고 destroy()메서드를 구현하면 된다.

ex. 데이터 베이스 커넥션 풀, 채팅 클라이언트

메서드 정의 인터페이스

• org.springframework.beans.factory.InitializingBean
• org.springframework.beans.factory.DisposableBean

//초기화 인터페이스
public interface InitializingBean {
    void afterPropertiesSet() throws Exception;
}

//소멸 인터페이스
public interface DisposableBean {
    void Destroy() throws Exception;
}

해당 코드를 수행하면 콘솔 화면에 매서드에서 정의한 "Client.afterPropertiesSet() 실행" 및 "Client.destroy() 실행"이 출력 됨

빈 객체 생성을 마무리한 뒤에 초기화 메서드를 실행한다.
또, 가장 마지막에 destroy() 메서드를 실행한다.

2. 빈 객체의 초기화와 소멸 : 커스텀 메서드

인터페이스로 상속받아 구현하는 것 말고 외부에서 제공받은 클래스를 스프링 빈 객체로 설정하고 싶을 때도 있다.

스프링 설정에서 직접 메서드를 지정할 수 있다.

@Bean태그에서 initMethod 속성과 destroyMethod 속성을 사용해서 초기화 메서드와 소멸 메서드의 이름을 지정하면 된다.

//Client2.java
        ...

// 직접 초기화 메서드 지정
public void connect(){
    System.out.println("Client2.connect() 실행");
}

// 직접 소멸 메서드 지정
public void close(){
        System.out.println("Client2.close() 실행");
}

        ...

이 메서드들을 @Bean 애노테이션의 initMethod 속성과 destroyMethod 속성에 사용될 메서드 이름인 connect와 close를 지정해주면 된다.

@Bean(initMethod = "connect", destoryMethod = "close") public Client2 clien2(){ ... }

초기화 메서드를 직접 실행할 때 초기화 메서드가 두 번 불리지 않다록 조심하자. afterPropertiesSet()이 두번 불릴 위험 있음

빈 객체의 생성과 관리 범위

// 한 식별자에 대해 한 개의 객체만 존재하는 빈
// 싱글톤 범위를 갖는다.
//client1 == client : true
Client client1 = ctx.getBean("client", Client.class);
Client client2 = ctx.getBean("client", Client.class);

------------------------
// client 빈의 범위가 프로토타입일 경우
// 매번 새로운 객체를 생성
// client1 != client : true
Client client1 = ctx.getBean("client", Client.class);
Client client2 = ctx.getBean("client", Client.class);

별도의 설정을 하지 않으면 싱글톤 범위를 갖는데, 특정 빈을 프로토 타입으로 빈을 설정할 수 도 있다. @Scope애노테이션을 사용해주면 된다.

@Bean
@Scope("prototype")
public Client client(){
        ...
}

• 싱글톤 범위를 명시적으로 지정해주고 싶으면 @Scope("singleton)이라고 해주면 된다.
• 프로토 타입은 별도의 소멸 처리를 코드에서 직접 해야 한다.

Reference.

'초보 웹 개발자를 위한 스프링5 프로그래밍 입문' 

• 자동 주입과 함께 사용되는 기능
• 스프링이 직접 클래스를 검색해서 빈으로 등록해주는 기능
• 설정 코드가 크게 줄어듦

Component-scan은 xml에 일일이 빈등록을 하지않고 각 빈 클래스에 @Component를 통해 자동 빈 등록이 된다.

@Component @Controller @Service @Repository와 같은 어노테이션을 자동 등록 처리해준다.

@Component 애노테이션으로 스캔 대상 지정

스프링이 검색해서 빈으로 등록할 수 있으려면 클래스에 @Component 애노테이션을 붙여야 한다.
이 애노테이션은 해당 클래스를 스캔 대상으로 표시한다.

• @Component 애노테이션에 값을 주면 그 값을 빈 이름으로 사용한다.
  ex. @Component("listPrinter")

@ComponentScan 애노테이션으로 스캔 설정

@Component 애노테이션을 붙인 클래스를 스캔해서 스프링 빈으로 등록하려면, 설정 클래스에 @ComponentScan 애노테이션을 적용해야한다.

@Configuration
@ComponentScan(basePackages = {"spring"})
public class AppCtx{
    ...
}

이 코드를 보면 AppCtx 클래스에서

@ComponentScan 애노테이션을 사용하여 @Component 애노테이션이 붙은 클래스를 검색해서 빈으로 등록해주기 때문에 설정 코드가 확연히 줄어든다.

또 컴포넌트 스캔 애노테이션을 살펴보면 basePackages 속성값은 {"spring"}이다. 이 속성은 스캔 대상 패키지 목록을 지정하는 것이다.
이는 spring 패키지와 그 하위 패키지에 속한 클래스를 스캔 대상으로 설정한다. 스캔 대상에 해당하는 클래스중 @Component 애노테이션이 붙은 클래스의 객체를 생성해 빈으로 등록한다.

스캔 대상에서 제외하거나 포함하기

excludeFilters 속성을 사용하면 스캔할 때 특정 대상을 자동 등록 대상에서 제외할 수 있다.

// 정규 표현식을 사용해서 제외 대상을 지정한다.
// "spring."으로 시작하고 Dao로 끝나는 정규 표현식을 지정
@ComponentScan(basePackages = {"spring"},
    excludeFilters = @Filter(type = FilterType.REGEX, pattern = "spring\\..*Dao"))





// AspectJ 패턴을 사용해 대상을 지정한다.
// spring 패키지의 Dao로 끝나는 타입을 지정
// AspectJ 패턴이 동작하려면 의존 대상에 aspectjweaver모듈을 추가해야한다.
@ComponentScan(basePackages = {"spring"},
        excludeFilters = @Filter(type = FilterType.ASPECTJ, pattern = "spring.*Dao"))





// 특정 애노테이션을 붙인 타입을 컴포넌트 대상에서 제외한다.
// 패턴은 Stringp[] 타입이므로 배열을 이용해 패턴을 한 개 이상 지정할 수 있다.
@ComponentScan(basePackages = {"spring", "spring2"},
        excludeFilters = @Filter(type = FilterType.Annotation, pattern = {NoProduct.class, ManualBean.class}))





// 특정 타입이나 그 하위 타입을 컴포넌트 스캔 대상에서 제외한다.
@ComponentScan(basePackages = {"spring"},
        excludeFilters = @Filter(type = FilterType.ASSIGNABLE_TYPE, classes = MemberDao.class))






// 설정할 필터가 2개 이상이면 excludeFilters 속성에 배열을 사용해서 목록을 전달하면 된다.
@ComponentScan(basePackages = {"spring"},
        excludeFilters = {
                @Filter(type = FilterType.ANNOTATION, classes = ManualBean.class),
                @Filter(type = FilterType.REGEX, pattern = "spring2\\..*")
        }

@Component 애노테이션을 붙인 클래스만 스캔 대상에 포함되는 것이 아니다.

• @Component
• @Controller
• @Service
• @Repository
• @Aspect
• @Configuration

@Aspect를 제외하고 나머지 애노테이션은 @Component 애노테이션에 대한 특수 애노테이션이다.

컴포넌트 스캔에 따른 충돌 처리

컴포넌트 스캔 기능을 사용해서 Bean을 등록할 경우, 아래와 같은 두 가지 충돌이 발생 가능

1. Bean 이름의 충돌
2. 수동 등록에 따른 충돌

2-1. Bean 이름 충돌

• 서로 다른 패키지에 같은 클래스의 이름이 존재하고, 두 클래스 모두 @Component 어노테이션이 붙게 된다면,
  Exception이 발생하게 됨
• 이럴 경우, 둘 중 하나에 명시적으로 Bean 이름을 지정해서 이름 충돌을 피해야 함
  
  

2-2. 수동 등록에 따른 충돌

1. 같은 클래스를 같은 이름으로 설정할 때:
   • @Component 어노테이션을 통해 이미 지정한 Bean의 클래스 이름이 존재하지만,
     클래스 설정에 직접 해당 클래스를 동일한 이름으로 정해 등록하는 경우 발생
   • 즉, 스캔할 때 사용하는 Bean 이름과 수동 등록한 이름이 같을 경우, 수동 등록한 Bean이 우선시 됨
2. 같은 클래스를 다른 이름으로 설정할 때:
   • 만약, 스캔할 때 사용하는 Bean 이름과 동일한 클래스를 다른 이름으로 수동 등록하는 경우에는
     다른 이름의 두 개의 Bean이 만들어지게 됨
   • 이런 경우에는 @Qualifier 어노테이션을 통해 알맞은 Bean을 선택해야 함

Reference.

'초보 웹 개발자를 위한 스프링5 프로그래밍 입문' link1

초보 웹 개발자를 위한 스프링 5 프로그래밍 입문
저자 : 최범균

CH 3. 스프링 DI

1. 의존이란 ?

• DI Dependency Injection 의존 주입
• 객체 간의 의존
• 의존은 변경에 의해 영향을 받는 관계를 의미한다.
• 의존하는 대상이 있으면 그 대상을 구현하는 방법이 필요하다.
  • 의존 객체를 직접 생성 ( 이 내용을 공부해보자 ) 
  • DI와 서비스 로케이터

2. DI를 통한 의존 처리

• 의존하는 객체를 전달받는 방식을 이용하는 DI

public class MemberRegisterService {
	
    // 직접 의존 객체 생성 
    private MemberDao memberDao = new MemberDao();
    
    //생성자를 통해서 의존 객체를 전달 받는 형식
    private MemberDao memberDao;
    public MemberRegisterService(MemberDao memberDao){
    	this.memberDao = memberDao;
    }
    
    ...
}

• 만약 MemberRegisterService 객체를 생성할 때 생성자에 MemberDao 객체를 전달해야 한다.

MemberDao dao = new MemberDao();
// 의존 객체를 생성자를 통해 주입한다.
MemberRegisterService svc = new MemberRegisterService(dao);

복잡해 보이는데 왜 생성자 통해서 의존하는 객체를 주입할까?
 -> 변경의 유연함을 위해서!!

3. DI와 의존 객체 변경의 유연함

• 의존 객체를 직접 생성하는 방식 = 필드나 생성자에서 new 연산자를 이용해 객체를 이용해 객체 생성

public class MemeberRegisterService {
	private MemberDao memberDao = new MemberDao();
    ...
}

이것과

public class ChangePasswordService {
	private MemberDao memberDao = new MemberDao();
    ...
}

이렇게 두개의 코드가 있는 상황.

캐시를 이용해 조회속도를 향상 시키고자 하는 상황이 발생...!!

memberDao -> cachedMemberDao 클래스를 만들어야 함~!~!

public class CachedMemberDao extends MemberDao {
	...
}

그렇다면 MemberRegisterService와 ChangePasswordService 모두 MemberDao에서 CachedMemberDao로 바꿔줘야함... ( 객체 생성시마다 하나하나 변경 해주어야 함... )

동일 상황에서 DI를 사용하면 수정 코드가 줄어든다...!!!  ( 클래스가 여러개여도 의존 주입 되상이 되는 객체를 생성하는 코드가 한곳이라, 객체 생성 코드에서만 변경하면 된다,) 

public class MemberRegisterService{
	private MemberDao memberDao;
    public MemberRegisterService(MemberDao memberDao){
    	this.memberDao = memberDao;
    }
    ...
}


public class ChangePasswordService{
	private MemberDao memberDao;
    public ChangePasswordService(MemberDao memberDao){
    	this.memberDao = memberDao;
    }
    ...
}


// --------------------------
// 위 뒤 클래스의 객체 생성시
// MemberDao memberDao = new MemberDao;
// 만 바꾸면 된다~!~!
MemberDao memberDao = new CachedMemberDao;

MemberRegisterService regSvc = new MemberRegisterService(memberDao);
ChangePasswordService pwdSvc = new ChangePasswordService(memberDao);

4. 예제 프로젝트 만들기

|---회원 데이터 관련 클래스
|  |---Member
|  |---WrongPasswordException
|  |---MemberDao
|
|---회원 가입 처리 관련 클래스
|  |---DuplicateMemberException
|  |---RegisterRequest
|  |---MemberRegisterService
|
|---암호 변경 관련 클래스
|  |---MemberNotFoundException
|  |---ChangePasswordService

5. 객체 조립기

• assembler
• 앞서 DI 설명 시 생성에 사용할 클래스를 변경하기 위해선, 객체를 주입하는 코드 한 곳만 변경하면 된다고 했다.
  • 실제 객체를 생성하는 코드는 어디에 있을까???
    • main 메소드에 의존 대상 객체를 생성하고 주입하는 방법이 나쁘진 않다. 
    • 더 나은 방법은 객체를 생성하고 의존 객체를 주입해주는 클래스를 따로 작성하는 것이다. (조립)

public class Assembler {

	private MemberDao memberDao;
    private MemberRegisterService memberRegisterService;
    private ChangePasswordService changePasswordService;
    
    // MemberRegisterService와 ChangePasswordService 객체에 대한 의존을 주입한다.
    // MemberRegisterService은 memberDao 객체를 주입받고,
    // ChangePasswordService는 setter를 통해 주입받는다.
    public Assembler(){
    	memberDao = new MemberDao();
        // memberDao = new CachedMemberDao();
        regSvc = new MemberRegisterService(memberDao);
        pwdSvc = new ChangePasswordService();
        pwdSvc.setMemberDao(memberDao);
    }
    ...
}

위와 같이 생성한 Assembler를 사용하는 코드는...??

-> Assembler 객체를 생성 - get 메서드를 이용해 필요한 객체를 구함 - 그 객체를 사용

Assembler assembler = new Assembler();
ChangePasswordService changePwdSvc = assembler.getChangePasswordService();
changePwdSvc.changePassword("이메일","비번","newpwd");

• Assembler 클래스의 생성자에서 필요한 객체를 생성하고 의존을 주입한다.
• 따라서 Assembler 객체를 생성하는 시점에 사용할 객체가 모두 생성된다.
• 그 후 Assembler가 제공하는 메서드를 이용해서 필요한 객체를 구하고, 그 객체를 사용하는 것이 전형적 패턴이다!

6. 스프링의 DI 설정

• 스프링은 MemberRegisterService와 MemberDao와 같은 특정 타입의 클래스만 생성한 Assembler와 달리 범용 조립기 역할을 한다....!!!
• 스프링을 사용하려면 우선 스프링이 어떤 객체를 생성하고, 의존을 어떻게 주입할지 정의한 설정 정보 작성 필수
• 설정코드는 주로 config 패키지~

// 스프링 설정 클래스를 의미하는 에노테이션
@Configuration
public Class AppCtx{
	
    // 해당 메서드가 생성한 객체를 스프링 빈이라고 설정하는 에노테이션
    // memberDao 메서드를 이용해서 생성한 빈 객체는 "memberDao"란 이름으로 스프링에 등록
    @Bean
    public MemberDao memberDao(){
    	return new MemberDao();
    }
    
    @Bean
    // MemberRegisterService 생성자를 호출할 때
    // memberDao()메서드를 호출하므로 memberDao()가 생성한 객체를
    // MemberRegisterService 생성자를 통해 주입
    public MemberRegisterService memberRegSvc(){
    	return new MemberRegisterService(memberDao);
    }
    
    @Bean
    public ChangePasswordService changePwdSvc(){
    	ChangePasswordService pwdSvc = new ChangePasswordService();
        // setMemberDao() 메서드를 이용해 의존관계를 주입한다
        pwdSvc.setMemberDao(memberDao());
    	return pwdSvc;
    }

• 설정 클래스를 만들었다고 끝이 아니다!!!!!!!
  • 컨테이너를 생성해야한다. ( 컨테이너 : 객체를 생성하고 의존 객체를 주입하는 역할 )

  • // 컨테이너 생성
    ApplicationContext ctx = new AnnotationConfigApplicationContext(AppCtx.class);
    
    
    // 컨테이너 생성 후 getBean() 메서드를 이용해 사용할 객체를 구할 수 있다.
    // 컨테이너에서 이름이 memberRegSvc인 빈 객체를 구한다.
    MemberRegisterService regSvc = ctx.getBean("memberRegSvc", MemberRegisterService.class);

DI 방식 1 : 생성자 방식

• 생성자를 통해 의존 객체를 주입받아 필드(this.memberDao)에 할당한다

private MemberDao memberDao;

// 생성자를 통해 의존 객체를 주입 받음
public MemberRegisterService(MemberDao memberDao){
	// 주입 받은 객체를 필드에 할당
    this.memberDao = memberDao;
}

public Long regist(RegisterRequest req){
	// 주입 받은 의존 객체의 메서드 사용
    Member member = memberDao.selectByEmail(req.getEmail());
    ...
    memberDao.insert(newMember);
    ...
}

• 생성자에 의해 전달할 의존 객체가 두 개 이상이어도 동일한 방식으로 주입하면 된다. 

// 생성자 파라미터가 두개인 예제를 살펴보자~!

public class MemberDao{
	...
    public Collection<Member> selectAll(){
    	return map.values();
    }
}


// =====================================================================
// 생성자로 두 개의 파라미터를 전달받는 클래스 작성
// MemberDao, MemberPrinter 객체를 전달 받는다.
public MemberListPrinter(MemberDao memberDao, MemberPrinter printer){
	this.memberDao = memberDao;
   	this.printer = printer;
}


// ======================================================================

7. @Configuration 설정 클래스의 @Bean 설정과 싱글톤

8. 두 개 이상의 설정 파일 사용하기

9. getBean( ) 메서드 사용

10. 주입 대상 객체를 모두 빈 객체로 설정해야 하나?

Field Injection(필드 주입)

변수 선언부에 @Autowired Annotation을 붙인다.

@Component
public class SampleController {
    @Autowired
    private SampleService sampleService;
}

필드주입을 사용하면 안되는 이유

1. 단일 책임(SRP)의 원칙 위반 

의존성을 주입하기가 쉽다.
@Autowired 선언 아래 개수 제한 없이 무한정 추가할 수 있다. Constructor의 parameter가 많아짐과 동시에 하나의 Class가 많은 책임을 떠안는다는 걸 알게된다.

2. 의존성이 숨는다. 

DI Container를 사용한다는 것은 Class가 자신의 의존성만 책임진다는게 아니라 제공된 의존성 또한 책임진다. 그래서 Class가 어떤 의존성을 책임지지 않을 때, 메서드나 생성자를 통해(Setter나 Constructor) 확실히 커뮤니케이션이 되어야한다.

하지만 Field Injection은 숨은 의존성만 제공해준다.

3. DI container의 결합성과 테스트 용이성

DI Framework의 핵심 아이디어는 관리되는 Class가 DI Container에 의존성이 없어야 한다.

DI Container 없이도 Unit Test에서 Instance화 시킬 수 있고, 각각 나누어서 테스트도 할 수 있다. Container의 결합성이 없다면 관리하거나 관리하지 않는 Class를 사용할 수 있고, 심지어 다른 DI Container로 전환할 수 있다.

하지만, Field Injection을 사용하면 필요한 의존성을 가진 Class를 곧바로 Instance화 시킬 수 없다.

4. 불변성

Constructor Injection과 다르게 Field Injection은 final을 선언할 수 없다. 그래서 객체가 변할 수 있다.

5. 순환 의존성

Constructor Injection에서 순환 의존성을 가질 경우 BeanCurrentlyCreationExeption을 발생시킴으로써 순환 의존성을 알 수 있다. 

그러나 Field Injection은 스프링 컨테이너 말고는 외부에서 주입할 수 있는 방법이 없다.

순환 의존성?
A Class가 B Class를 참조하는데 B Class가 다시 A Class를 참조할 경우,A Class가 B Class를 참조하고, B Class가 C Class를 참조하고 C Class가 A Class를 참조하는 경우 이를 순환 의존성(Circular Dependency)이라고 부른다.

읽기 쉽고 사용이 편하단것 이외엔 장점이...

Setter Injection(수정자 주입)

Setter Injection은 선택적인 의존성을 사용할 때 유용하다. 상황에 따라 의존성 주입이 가능하다.

//Setter Injection은 set Method를 정의해서 사용한다.
@Component
public class SampleController {
    private SampleService sampleService;
 
    @Autowired
    public void setSampleService(SampleService sampleService) {
        this.sampleService = sampleService;
    }
}

Setter Injection으로 의존관계 주입은 런타임시에 할 수 있도록 낮은 결합도를 가지게 구현되었다.

하지만 Setter Injection을 통해서 Service의 구현체를 주입해주지 않아도 Controller 객체는 생성이 가능하다.

Controller 객체가 생성가능하다는 것은 내부에 있는 Service의 method 호출이 가능하다는 것인데, set을 통해 Service의 구현체를 주입해주지 않았으므로, NullPointerException 이 발생한다.

주입이 필요한 객체가 주입이 되지 않아도 얼마든지 객체를 생성할 수 있다는 것이 문제다.

이를 해결할 아이가 Constructor Injection이다

Constructor Injection(생성자 주입)

//Constructor에 @Autowired Annotation을 붙여 의존성을 주입받을 수 있다.
@Component
public class SampleService {
    private SampleDAO sampleDAO;
 
    @Autowired
    public SampleService(SampleDAO sampleDAO) {
        this.sampleDAO = sampleDAO;
    }
}

@Component
public class SampleController {

	private final SampleService sampleService = new SampleService(new SampleDAO());
    
	...
}

생성자 주입을 사용해야하는 이유!!!

(Spring Framework Reference에서 권장하는 방법은 생성자를 통한 주입~!)

생성자를 사용하는 방법이 좋은 이유는 필수적으로 사용해야하는 의존성 없이는 Instance를 만들지 못하도록 강제할 수 있기 때문이다.

Spring 4.3버전부터는 Class를 완벽하게 DI Framework로부터 분리할 수 있다.

단일 생성자에 한해 @Autowired를 붙이지 않아도 된다.

또한 앞서 살펴본 Field Injection의 단점들을 장점으로 가져갈 수 있다.

• null을 주입하지 않는 한 NullPointerException 은 발생하지 않는다.
• final 을 사용할 수 있다.
• 순환 의존성을 알 수 있다.
• 의존성을 주입하기가 번거로워 위기감을 느낄 수 있다. (이를 바탕으로 SRP원칙을 생각하게 되고 리팩토링하게된다.)

Reference.

link1

스프링의 삼각형
DI IoC AOP

스프링의 기반이 되는 설계 개념인 스프링의 삼각형

의존성 주입 DI ( Dependency Injection )

Inversion of Control 이라고도 하는 의존 관계 주입(Dependency Injection)이라고도 하며, 어떤 객체가 사용하는 의존 객체를 직접 만들어 사용하는게 아니라, 주입 받아 사용하는 방법이다. (new 연산자를 이용해서 객체를 생성하는 것이라고 생각하면 된다) 스프링이 다른 프레임워크와 차별화되어 제공하는 의존 관계 주입 기능으로, DI(의존성 주입)를 통해서 모듈 간의 결합도가 낮아지고 유연성이 높아진다.

A 객체에서 B, C객체를 사용(의존)할 때, A 객체에서 직접 생성 하는 것이 아니라 외부(IOC컨테이너)에서 생성된 B, C객체를 조립(주입)시켜 setter 혹은 생성자를 통해 사용하는 방식 

예시로 장난감과 배터리를 들 수 있다. 장난감들은 베터리가 있어야 움직일 수 있으며 즉 베터리에 의존하고 있다. 장난감들에게 베터리를 넣어주는 것을 의존성 주입이라고 생각하면 좋다.

베터리의 일체형인 경우에는 생성자에서만 의존성을 주입해주는 상황이라 베터리가 떨어지게 된다면 다른 베터리로 교체하지 못하고 새로운 것으로 바꿔야 하기 때문에 유연하지 못한 방식이다. 

자바와 같은 경우엔 setter, 생성자를 이용해서 외부에서 주입해주는 상황은 외부에서 베터리를 교체해줄 수 있기 때문에 일체형보다 유연한 상황이다. 

스프링에서는 객체를 Bean이라고 부르며, 프로젝트가 실행될때 사용자가 Bean으로 관리하는 객체들의 생성과 소멸에 관련된 작업을 자동적으로 수행해주는데 객체가 생성되는 곳을 스프링에서는 Bean 컨테이너라고 부른다.

의존성 주입을 사용하는 이유

1. 재사용성을 높여준다.

2. 테스트에 용이하다.

3. 코드를 단순화 시켜준다.

4. 사용하는 이유를 파악하기 수월하고 코드가 읽기 쉬워지는 점이 있다.

5. 종속성이 감소하기 때문에 변경에 민감하지 않다.

6. 결합도(coupling)는 낮추면서 유연성과 확장성은 향상 시킬 수 있다.

7. 객체간의 의존관계를 설정할 수 있다.

Reference.

link1 link2