개요
스프링은 객체지향적 설계를 도와주는 프레임워크이다. 그러나 스프링을 사용하지 않고 순수 자바로 코딩했을 때 어떤 불편함이 있는지, 프레임워크에 맡기지 않고 개발자가 컨트롤 했을 때는 어떤 그림이 나오는지 배워두는 것도 매우 의미있는 일일 것 같다.
형태
위는 OrderServiceImpl 이라는 클래스이며, 이 클래스는 현재 memberRepository, discountPolicy라는 추상(인터페이스) 에 의존하고 있다.
- 사실 이 그림 스프링에서 굉장히 굉장히 익숙하다. 저 class위에 @RequiredArgsConstructer / @Component 달면 아~! 그냥 final 달린 저 친구들 생성자가 하나라 스프링이 DI 해줬구나!
- 그러나 자바로 한다면, 한 가지 과정이 더 필요하다. 스프링 프레임워크가 우리 대신 DI를 해줬듯, 우리는 DI를 해 줄 친구를 우리가 만들어서 써야한다.
위와 같이 멤버서비스가 새 Impl 객체를 정의해주고, 이 Imple이 어떤 Repository를 의존(바라본다, 알고있다, 참조한다)할 것인지를 여기서 정해준다.
- 강의에서는 마치 영화에서 배우의 캐스팅을 여기서 한다고 비유했다.
- 배우 1,2인 MemberServiceImpl, OrderServiceImpl은 그저 자신이 맡은 바 임무만 충실히 수행하고
- 여기서 상대역을 누구를 배정해줄지를 정한다.(MemoryMemberRepository, DiscountPolicy -> FixDiscountPolicy)
따라서 위 그림처럼 구현체 에서는 강한 결합이 아닌 느슨한 결합으로
- 변경에 대한 비용이 최소화되며, SOLID 중 OCP/DIP를 만족하게 된다
더하여 다시한번,
- 구현체인 OrderServiceImpl 은 MemberRepository에 어떤 구현체가 실제로 있는지 알지 못하고, 알 필요가 없다. 그 역할은 모두 다 Appconfig에서 해주기 때문.
알게 된 점
- 스프링을 사용하면서도 왜 스프링을 써야하나, 왜 이렇게 어렵고 외울 게 많은 친구를 써야하는지 잘 이해가 안됐던 부분이 있었다.
- 결국, 스프링을 쓰면서도 강한 결합을 사용하는 날 발견했었고, 변경에 대한 비용이 엄청나게 크다는 걸 느꼈다.
위와 같이 순수 자바 코드로 의존성을 주입하는 일련의 과정들을 보니 의존성 주입이 왜 사용되어야 하는지, 또 어떤 원리로/동작으로 사용되는지 알 수 있었다.
- 특히 프레임워크 는 라이브러리와 다르게 제어권이 프레임워크에 있다! 라는 말이 더 이해가 됐다. 제어의 역전! IoC!
- 스프링은 추상화를 원활하게 해주는 툴이구나!
