기존 Code들을 살펴보면 정책이 변경될 때마다 구체 클래스를 수정했어야 했다.
-
관심사 분리
AppConfig을 개발을 해서 외부에서 따로 구성하고 연결하는 책임을 갖는다. -
새로운 정책 적용
AppConfig를 설정하므로 인하여, 사용 여역과 객체를 생성하고 구성하는 영역으로 분리
할인 정책을 변경하더라도 AppConfig가 있는 구성 영역만 변경하면 된다.
좋은 객체 지향 설계의 5가지 원칙 적용
- SRP
한 클래스는 하나의 책임을 갖는다.
- 클라이언트 객체는 직접 구현 객체를 생성, 연결, 실행
- SRP 단일 책임원칙을 따르면서 관심사 분리
- 구현 객체를 생성, 연결 -> AppConfig가 담당
- DIP
추상화에 의존, 구체화에 의존하면 안된다. = (외부에서 넣어주어야 한다) 의존성 주입은 이 원칙을 따르는 방법 중 하나.
새로운 할인 정책을 개발하고, 적용하려고 하니 클라이언트 코드도 함께 변경해야 했다. 왜냐하면 기존 클라이언트 코드( OrderServiceImpl )는 DIP를 지키며 DiscountPolicy 추상화 인터페이스에 의존하는 것 같았지만, FixDiscountPolicy 구체화 구현 클래스에도 함께 의존했다.
클라이언트 코드가 DiscountPolicy 추상화 인터페이스에만 의존하도록 코드를 변경했다.
하지만 클라이언트 코드는 인터페이스만으로는 아무것도 실행할 수 없다.
AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트
코드에 의존관계를 주입했다. 이렇게해서 DIP 원칙을 따르면서 문제도 해결했다
- OCP
software 요소는 확장에는 열러있으나 변경에는 닫혀 있다.
다형성 사요으 DIP를 지킴
애플리케이션 사용 영역과 구성 영역을 나눔
AppConfig가 의존관계를 FixDiscountPolicy RateDiscountPolicy 로 변경해서 클라이언트
코드에 주입하므로 클라이언트 코드는 변경하지 않아도 된다.
확장은 해도 변경에는 닫혀있다. (외부에서 바꾸면 됨) == AppConfig
Ioc, DI 그리고 Container
제어의 역전
내가 뭔가 호출 하는것이 아닌 framework가 대신 호출 = 제어권이 바뀐다 해서 제어의 역전
기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체 생성 & 연결
구현 객체가 프로그램 제어 흐름 스스로 조종
외부 설정 하는 AppConfig같은 것이 등장 하면서 구현 객체는 자신의 로직을 실행하는 부분만!
구현 객체는 어떤 것이 호출 되는지를 모른다.
제어권이 다 AppConfig로 넘어갔다 = 제어의 역전
프레임워크 vs 라이브러리
프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit = teat)
반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다
의존관계 주입 DI
의존관계는 정적인 클래스 의존관계와 실행 시점에 결정되는 동적 객체 의존 관계 둘을 분히해서 생각
정적 클래스 의존 관계 (클래스 코드만 열어서 판단)
클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단 가능! 정적 의존관계는 애플리케이션 실행하지 않아도 분석 가능
클래스 다이어 그램을 확인해보면, 의존 관계는 알수 있지만, 클래스 의존관계만으로 실제 어떤게 주입 될지 알 수 없다.
동적인 객체 인스턴스 의존관계
애플리케이션 실행 시점 -> 실제 생성된 객체 인스턴스 참조가 연결된 의존관계
애플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성, 클라이언트에 전달 -> 클라이언트와 서버의 실제 의존관계 연결 되는 것을 의존관계 주입!
객체 인스턴스 생성, 참조값을 전달 -> 연결 (주소값이 들어 있다)
의존관계 주입을 사용, 클라이언트 코드 변경X -> 호출하는 대상 타입 인스턴스를 변경 가능
의존관계 주입을 사용하면 정적인 클래스 의존관계 변경 X,
동적 객체 인스턴스의 의존관계 쉽게 변경 메모리 저장소로 할지, 정률, 정액 할인을 할지
logic을 건들지 않고 변경 가능
Ioc container / DI container
의존관계 역전을 일으키는 = IocContainer or DI Container
