인프런 김영한 님의 <스프링 핵심 원리 - 기본편> 강의 내용을 정리한 것입니다.
관심사의 분리
애플리케이션 : 인터페이스 = 공연 : 배역
공연을 할 때 배우는 자신의 배역만을 수행하는 것에 집중해야 한다. 상대 배역의 담당 배우가 바뀌더라도 똑같이 공연할 수 있어야 한다.
배역 외에 공연과 관련한 업무는 '공연 기획자'가 필요하다.
공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실하게 분리하여야 한다.
AppConfig
public class AppConfig {
public MemoryMemberRepository memberRepository() {
return new MemoryMemberRepository();
}
public DiscountPolicy discountPolicy() {
return new RateDiscountPolicy();
}
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
public OrderService orderService() {
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
}애플리케이션 전체 동작 방식을 구성하기 위해 구현 객체를 생성 및 연결하는 책임을 갖는 별도의 설정 클래스.
공연 기획자의 역할.
AppConfig를 둠으로써 '객체를 생성하고 연결하는 역할'과 '실행하는 역할'을 명확히 분리할 수 있게 되었다.
IoC, DI, 컨테이너
제어의 역전 (IoC)
프로그램의 제어 흐름은 외부에서 관리하고, 프로그램은 그 자체의 로직만 실행하는 것.
기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성, 연결, 실행했다. 다시 말해, 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다.
AppConfig가 등장한 이후 구현 객체는 자신의 로직을 실행하는 역할만 담당하고, 프로그램 제어 흐름 권한은 모두 AppConfig가 가져간다.
의존관계 주입, DI
관심사를 분리해줌으로써 구현 객체를 실행하는 쪽은 인터페이스에 의존하여 실제 어떤 구현 객체가 사용될지는 모른다.
의존관계는 "정적인 클래스 의존관계"와 "실행 시점에 결정되는 동적인 객체 인스턴스 의존관계" 둘을 분리해서 생각해야 한다.
- 정적 클래스 의존관계 : 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단 가능. 그러나 이러한 클래스 의존관계만 보고는 실제로 어떤 객체가 주입되는지는 알 수 없다.
- 동적 객체 인스턴스 의존관계 : 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존관계.
의존관계 주입
- 애플리케이션 실행시점(런타임)에 외부에서 실제 구현 객체를 생성하고, 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것.
- 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.
- 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
- 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.
IoC 컨테이너, DI 컨테이너
AppConfig처럼 객체를 생성, 관리하면서 의존관계를 연결해주는 것을 IoC 컨테이너 혹은 DI 컨테이너라 한다.
스프링 컨테이너
ApplicationContext를 스프링 컨테이너라 한다.
스프링 컨테이너는 @Configuration 이 붙은 AppConfig를 설정(구성) 정보로 사용한다. 여기서 @Bean 이 붙은 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.
스프링 빈은 @Bean 이 붙은 메서드명을 스프링 빈 이름으로 사용한다.
