관심사의 분리, AppConfig

문제 상황

DIP(추상화에 의존해야지 구체화에 의존하면 안된다)에 의해 인터페이스에만 의존해야 하는데 인터페이스만 선언하면 구현체가 할당이 안되있기 때문에 NullpointException 뜸

public class OrderServiceImpl implements OrderService{
	private Discountpolicy discountpolicy;	// nullPointException
}

 

그럼 new로 구현체를 할당해주면 만약 구현체가 바뀌어야 한다면 클라이언트의 코드를 변경해야 됨

public class OrderServiceImpl implements OrderService{
	private Discountpolicy discountpolicy = new FixDiscountPolicy;
}

-> OCP 위반, 클라이언트가 인터페이스와 구현체 모두 의존하고 있기 때문에 DIP도 위반.

=> 외부에서 누군가가 클라이언트인 OrderServiceImpl에 Discountpolicy의 구현체를 대신 생성하고 주입해줘야 한다.

 

관심사의 분리

배우가 상대 배역을 직접 정하지 않고 감독이 정하듯이 이 감독 역할을 AppConfig가 할 것. 

 

AppConfig

애플리케이션 전체를 설정하고 구성한다. 구현 객체를 생성하고 연결하는 책임을 가지는 별도의 설정 클래스.

객체를 생성하고 주입하는 부분 이제 여기서 다 하는 것.

 

 

이제 OrderServiceImpl는 어떤 구현 객체가 들어올지 모름. 나는 의존관계는 이제 신경쓰지 않고 인터페이스에 맞춰서  기능 구현에만 집중. 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정된다.

생성자로 주입한다고 해서 생성자주입

 

-> OrderServiceImpl에 할인 정책 주입할 때 fixed에서 rate로 바뀐다고 해도 OrderServiceImpl은 바꿀 필요 없이 AppConfig에서 DiscountPolicy 구현체 생성해서 주입해주는 부분만 rate로 바꾸면 된다.

AppConfig만 변경하면 됨!

 

구성 영역은 당연히 변경된다. 공연 기획자는 공연 참여자인 구현 객체들을 모두 알아야 함

진짜 중요한 것은 사용영역은 전혀 바뀌지 않는 다는 것! 클라이언트의 코드는 손대지 않아도 된다. 객체 지향에서 중요한 것은 역할과 구현을 분리하는 것.

 

 

 

출처 : 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/dashboard

스프링 핵심 원리 - 기본편 강의 - 인프런