[스프링 기본] 섹션 3. 스프링 핵심 원리 이해2 - 객체 지향 원리 적용

새로운 할인 정책 개발

RateDiscountPolicy 추가

새로운 할인 정책 적용과 문제점

=> 인터페이스에만 의존하도록 설계를 변경하자
 
해결방안
이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpld에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해주어야 한다.

관심사의 분리

이전 코드는 배우가 기획도 하고 여자주인공 다 섭외해야 하는 "다양한 책임"을 가지고 있었다.
관심자를 분리하자.
 
AppConfig 등장
애플리케이션의 전체 동작 방식을 구성하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 변도의 설정 클래스를 만들자.
 
AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.
- MemberServiceImpl
- MemoryMemberRepository
- OrderServiceImpl
- FixDiscountPolicy
AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입해준다
- MemberServiceImpl -> MemoryMemberRepository
- OrderServiceImpl -> MemoryMemberRepository, FixDiscountPolicy
 
MemberServiceImpl - 생성자 주입
- 설계 변경으로 MemberServiceImpl은 MemoryMemberRepository를 의존하지 않는다!
- 단지 MemberRepository 인터페이스만 의존한다
- MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지는 알 수 없다
- MemberServiceImpl의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부 (AppConfig)에서 결정된다.
- MemberServiceImpl은 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 된다.
 
클래스 다이어그램

회원 객체 인스턴스 다이어그램

정리
- AppConfig를 통해서 관심사를 확실하게 분리했다.
- 배역, 배우를 생각해보자
- AppConfig는 공연 기획자다.
- AppConfig는 구체 클래스를 선택한다. 배역에 맞는 담당 배우를 선택한다. 애플리케이션이 어떻게 동작해야 할지 전체 구성을 책임진다.
- 이제 각 배우들은 담당 기능을 실행하는 책임만 지면 된다.
- OrderServiceImpl은 기능을 실행하는 책임만 지면 된다.
 

AppConfig 리팩터링

새로운 구조와 할인 정책 적용

AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성하는 영역으로 분리되었다.

전체 흐름 정리

- 새로운 할인 정책 개발
- 새로운 할인 정책 적용과 문제점
- 관심사의 분리
- AppConfig 리펙터링
- 새로운 구조와 할인 정책 적용

좋은 객체 지향 설계의 5가지 원칙의 적용

SRP 단일 책임 원칙
한 클래스는 하나의 책임만 가져야 한다.
 
DIP 의존관계 역전 원칙
프로그래머는 "추상황에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
 
OCP
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

IoC, DI, 그리고 컨테이너

클래스 다이어그램

객체 다이어그램

IoC 컨테이너, DI 컨테이너
- AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을
- IoC 컨테이너 또는 DI 컨테이너라 한다.
- 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다
- 또는 어셈블러, 오브젝트 팩토리 등으로 불리기도 한다.

스프링으로 전환하기

강사님과 함께 라이브 코딩 진행하면 된다.
 

글에서 나오는 코드와 내용은 김영한님의 인프런 스프링 기본 강의에서 가져온 것을 알립니다.