🤗 인프런 [스프링 핵심원리-기본편]을 듣고 기록하는 글입니다
진행 과정
※ SOLID 중 SRP, DIP, OCP가 어떻게 적용됐는지 이론설명
학습 내용
SRP 단일 책임 원칙
한 클래스는 하나의 책임만 가져야한다
문제사항 :
전에는 Service가 구현객체를 정하고 연결하는등의 다양한 책임을 가지고 있었음
해결방법 :
1. 구현객체를 생성하고 연결하는 책임을 AppConfig에게 넘겨줌
2. 클라이언트 객체는 실행하는 책임만 담당
DIP 의존관계 역전 원칙
객체는 추상화에 의존해야지, 구체화에 의존하면 안된다.
문제사항 :
OrderServiceImpl가 DiscountPolicy라는 추상화 interface에 의존하는것 같았지만, FixDiscountPolicy라는 구체화 구현 클래스에도 의존했었음
해결방법 :
1. 클라이언트 코드가 DiscountPolicy에만 의존하도록 코드를 변경
2. 구현체 주입 부분이 사라졌기 때문에 문제가 생김
3. AppConfig를 만들어서 FixDiscountPolicy 객체 인스턴스를 대신 생성해주는 방식으로 의존관계 주입
OCP 개방-폐쇄 원칙
문제사항 :
사용영역에서 구성도 담당했기 때문에 소프트웨어 요소를 확장하면 클라이언트 코드도 어쩔 수 없이 변경이 됐었음
해결방법 :
1. application을 사용영역(Service등)과 구성영역(AppConfig)으로 나눔
2. AppConfig에서 FixDiscountPolicy를 RateDiscountPolicy로 변경을 하고, 그게 클라이언트 코드에 주입되는것이므로 클라 코드는 변경이 안됨
3. 그래서, 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀있음.
IoC
프로그램의 제어 흐름을 직접 제어하는 것이 아니라, 외부에서 관리하는 것.
※ 프레임워크 vs 라이브러리
- 프레임워크는 내가 작성한 코드를 제어하고, 대신 실행해줌
- 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 라이브러리
DI
의존관계 주입이라고 부름
의존관계는 1)정적인 클래스 의존관계 2)실행 시점에 결정되는 동적인 객체(instance)의 의존관계로 둘로 분리해서 생각해야함
- 정적인 의존관계
- 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단가능.
- app을 실행하지않아도 알 수 있음.
- 동적인 의존관계
- app 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 관계
- 런타임에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는것을 DI라고 부름
- 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결됨.
컨테이너
- appconfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는것 (IoC컨테이너 또는 DI 컨테이너라고 부름)
- 요즘에는 DI 컨테이너라고 자주부름. 왜냐하면 IoC는 정말 다양한 곳에서 일어나고, 범용적이라서 DI라는 용어를 많이 쓴다고함.
