섹션 2. 스프링 핵심 원리 이해1 - 예제 만들기
미확정된 요구사항에 대해서는 인터페이스를 만들고 구현체를 선택
섹션 2에서는 요구사항을 순수 자바코드로 작성하고 테스트함
→ 테스트를 JUnit으로 한번 더 하는데 이때,
테스트 코드 작성시 given, when, then 문법 활용
- given : ~~ 가 주어졌을때
- when : ~~ 했을때
- then : 이렇게 됨
검증에는 assertJ 라이브러리의 Assertions.assertThat . isEqualTo 메서드 사용
섹션 3. 스프링 핵심 원리 이해2 - 객체 지향 원리 적용
새로운 정책을 확장해야할 때, 기존 코드를 객체 지향 설계 원칙을 잘 따라서 작성했다면 유연한 설계가 가능
새로운 클래스의 테스트 클래스 생성 커맨드 : cmd + shift + T
섹션 3에서는 새로운 정책을 추가하여 기존 정책과 교체함.
클라이언트 코드가 정책의 인터페이스와 구체 클래스에 모두 의존 → DIP 위반
따라서, 정책을 변경하려면 클라이언트 코드를 고쳐야함 → OCP 위반
누군가 구현 객체를 대신 생성하고 주입하여 문제를 해결해야함.
- → AppConfig : 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고 연결하는 책임을 갖는 별도의 설정 클래스
클라이언트 입장에서는 의존관계를 마치 외부에서 주입
- → DI(Dependency Injection) 의존성 주입
IoC(Inversin of Control)
: 프로그램의 제어 흐름을 직접 제어하는 것이 아니라, 외부에서 관리하는 것
프레임워크 vs 라이브러리
- 프레임워크 : 내가 작성한 코드를 대신 제어
- 라이브러리 : 내가 작성한 코드를 직접 제어
DI(Dependency Injection)
: 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서
클라이언트와 서버의 실제 의존관계가 연결 되는 것
의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을
분리해서 생각해야 함.
- 정적인 클래스 의존관계
- → 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다. 정적인 의존관계는
애플리케이션을 실행하지 않아도 분석할 수 있다.
- → 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다. 정적인 의존관계는
- 동적인 객체 인스턴스 의존 관계
- → 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.
⇒ DI를 통해 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.
IoC 컨테이너, DI 컨테이너 : AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 주입해주는 것
- DI에 초점을 맞추어 최근에는 주로 DI 컨테이너라고 함.
- 어셈블러, 오브젝트 팩토리 등으로도 불림.
스프링으로의 전환
- AppConfig에 @Configuration 추가, @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록
- → 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 함
- 스프링은
ApplicationContext로 시작 (스프링 컨테이너) - 이전까지는 AppConfig 를 사용해서 직접 객체를 생성하고 DI 주입
- → 이제부터는 스프링 컨테이너를 통해서 사용
