3. 스프링이 필요한 이유

할인 정책을 FixDiscount -> RateDiscount로 바꾸게 된다면 어떤 문제가 발생할까?

 

문제점

• 새로운 할인 정책으로 바꾸게 된다면 클라이언트 코드에서 수정이 불가피하다.

//private final DiscountPolicy discountPolicy= new FixDiscountPolicy();
private final DiscountPolicy discountPolicy= new RateDiscountPolicy();

 

왜 수정이 불가피 한가?

해당 코드는 인터페이스 뿐만아니라 구체화된 클래스에도 의존하고 있기 때문에 DIP원칙을 위배하게 되어 

새로운 정책을 적용시키기 위해서 OCP 원칙 마저 위배하게 되는 것이다. 

 

---

해결방안

그렇다면 DIP를 위반하지 않도록 인터페이스에만 의존하도록 코드를 변경하면 어떨까?

private final DiscountPolicy discountPolicy;

 

하지만 이렇게 코드를 변경하면 DIP 원칙에는 맞지만  discountPolicy라는 객체가 없기 때문에 NullPointerException이 발생하게된다. 

 

따라서 누군가 대신 객체를 생성하고 주입해줘야하는 문제가 발생하게 된다.

이 역할을 누가 해주면 될까??

 

바로 이 점에서 우리는 스프링이 필요한 것이다.

 

다음 포스트에서는 어떻게 이 문제점을 해결할 수 있는지 알아보도록 하자