[스프링 기본] appConfig로 구현체 주입하기

🤗 인프런 [스프링 핵심원리-기본편]을 듣고 기록하는 글입니다

진행 과정

---

※ 기존 코드에다가 좋은 객체 지향 원리를 적용하는 과정을 거칠 예정

테스트코드

• VIP일때, 일반회원일때의 testcode를 모두 작성해보았으며, 일부로 일반회원 testcode는 오류가 나게끔 구현해봄

• vip_x() 테스트 함수에 isEqualTo(0);으로 바꾸니까 두 테스트 모두 오류 없이 잘 돌아가는거 볼 수있음

• ServiceApp에서, appconfig를 통해 serviceImpl에 들어갈 구현체를 설정

• ServiceTest에서 역시 appconfig를 통해 구현체 설정

학습 내용

---

테스트 코드

1. 이번 예제에서는 간단하게 그냥 10%할인이라 해놓고 간단하게 테스트해봤지만, 사실 이런 비율할인의 경우에는 구현하기가 굉장히 어려움.
2. 실무에서는 경계값 확인용 test code도 짜는둥 많은 test를 거쳐봐야함
3. 그리고 지금은 간단하기도 하고, 구조도 잘 짜놔서 이렇게 할인만 집중적으로 test를 해볼 수 있는것! (서비스부분하고 할인을 떼어놓았으니까)

할인정책 구현체 변경적용하기

1. 새로 만든 할인 정책으로 변경하려면, OrderServiceImpl 코드를 고쳐야함

2. 문제점 발생

   • 역할 구현을 충실하게 분리 → YES

   • 다형성 활용, interface와 구현 객체 분리 → YES

   • OCP, DIP 같은 객체지향 설계 원칙을 지킴 → NO

     • 그렇게 보이지만 아님
     • ServiceImpl가 DiscountPolicy라는 interface뿐만 아니라, FIx&RateDiscountPolicy인 구현체에도 의존중임. 그러므로 DIP 위반
     • DIP를 위반하고 구현체에도 의존을 하니까 할인정책 변경을 하려고 하면 ServiceImpl를 변경하게 됨. 즉, OCP 위반

3. DiscountPolicy에만 의존하도록 변경해보자

   • ServiceImpl안에 DiscountPolicy만 선언하기 → 고런데 이러면 당연히 구현체가 안들어있으니까 nullPointException 터짐
   • ServiceImpl에 할인 구현체를 대신 생성해주고 주입해주는 무언가를 만들어줘야함.

관심사의 분리

• 배우와 역할로 생각을 했을때, 배역에 맞는 배우를 선택하는것은 누구인가?
• 만일 배우가 직접 상대배우를 구한다면, 이건...망한 중소배역사가 아닌이상 이렇게 하지 않는다. 당연히 감독이 있고, 이들이 배역을 선정한다!
• 배우가 모든일을 하게되면 너무 많고 다양한 책임을 가지게됨. 관심사가 분리되지 않은것
• 구현체 할당해주는 config를 생성해주자

1. AppConfig가 실제 동작에 필요한 구현 객체를 생성
2. AppConfig는 생성한 객체 인스턴스를 생성자를 통해 주입한다.
3. ServiceImpl은 이제 의존관계 고민은 외부에 맡기고, 실행에만 집중하면됨.

꿀팁들

---

1. ctrl + E 누르면 기존 히스토리가 다 보임