스프링의 핵심 원리 이해 - 객체 지향 원리 적용

새로운 할인 정책

이 코드는 문제점이있다. 다형성도 활용하고 인터페이스와 구현을 분리했다. 하지만 OrderServiceImpl은 DiscountPolicy와 구현체인 FixDiscountPolicy,RateDiscountPolicy에도 의존하고 있다. -> DIP위반 또한 기능을 확장해서 변경하면 클라이언트의 코드가 변경된다. -> OCP위반

이렇게 사용할 경우 구연체가 없어서 오류가 발생하게 된다.

 

관심사를 분리하자

구현 객체를 생성하고 연결하는 책임을 가지는 별도의 클래스를 만들어서 사용하자 

이것이 AppConfig이다.

 

이런식으로 생성자를 주입해준다. 그러면 생성자가 생성되는 시점에 기능이 주입되게 된다. 그렇게 된다면 AppConfig만의 변경으로 기존코드의 변경없이 기능을 확장시킬 수 있다. --> OCP만족

 

이제 구현체들은 실행에만 집중하면 된다.

 

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

 

 

Framework vs Library

프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다.

반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.

 

IoC, DI, 그리고 컨테이너

 

제어의 역전(Inversion of Control)

기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다.

이말은 즉 구현 객체가 프로그램의 흐름을 스스로 제어했다는 것이다. 이것은 개발자 입장에서는 자연스러운 일이다.

 

위에 그림은 보면 이제는 구성영역의 AppConfig가 인터페이스의 구현체를 생성해주고 있다. 이렇듯이 프로그램이 제어 흐름을 가지는것이 아닌 외부에서 관리하는것을 제어의 역전이라고 한다.

 

의존관계 주입(Dependency Injection)

그림을 보면 OrderServiceImpl은 DiscountPolicy에 의존한다. 실제로는 어떤 구현 객체가 사용될지는 모른다.

 

이러한 의존관계는 정적인 의존관계와 동적인 의존관계로 분류될 수 있다.

정적인 의존관계는 import를 보면 쉽게 확인 할 수 있다.

동적인 의존관계는 실행 시점에 실제 생성된 인스턴스의 참조를 확인해야 한다.

 

이렇게 어플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달 클라이언트와 서버의 실제 의존 관계가 연결  되는 것을 의존관계 주입이라고 한다. 

 

장점

 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.

 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8