본 게시글은 김영한님의 스프링 핵심 원리 기본편을 정리한 글입니다.
이전 시간 AppConfig라는 기획자 역할의 코드를 리팩토링을 하였다. 이제는 본격적으로 새로운 할인 정책을 좋은 객체 지향 설계에 맞게 수정하고 이때까지 한 것에 대해 잠시 Refresh 하는 시간을 가져보자.
❗ 새 할인 정책 적용하기
Before
public class AppConfig{
public MemberService memberService(){
return new MemberServiceImpl(memberRepository());
}
public OrderService orderService(){
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
public MemberRepository memberRepository(){
return new MemoryMemberRepository();
}
public DiscountPolicy discountPolicy(){
return new FixDiscountPolicy();
}
}After
public class AppConfig{
public MemberService memberService(){
return new MemberServiceImpl(memberRepository());
}
public OrderService orderService(){
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
public MemberRepository memberRepository(){
return new MemoryMemberRepository();
}
public DiscountPolicy discountPolicy(){
// return new FixDiscountPolicy();
return new RateDiscountPolicy();
}
}위 코드를 변경하는 것은 이제 한 줄만 변경이 되어서 별 뭐 음.... 느낌이 팍 오지는 않지만 실제로는 이런 그림과 같은 과정이 일어난 것이다.
위와 같이 사용영역에는 어떠~~~한 영향도 미치지 않고 그냥 갈아끼우는 느낌으로 정책만 변경이 되었다.
이런 식으로 변경을 하는것이 이전에 말하였던 여러가지 객체지향 법칙(SRP, OCP, DIP) 와 같은 것들을 잘 지키면서 효율적으로 코드를 짤 수 있다는 것을 알 수 있었다. 앗.. DI 포함해서
정리 해 보는 시간
5 챕터를 진행하면서 상당히 여러가지 많은 부분들에 대해서 공부를 하고 코드도 수정도 하는 시간을 가졌다. 크게 기억나는 것들에 대해서 말을 해 보자면
- 비즈니스 설계 방식대로 도메인, 할인정책 구현
- 할인정책을 변경하기 위하여 고민해야 할 것들
- 새로운 할인정책 적용
이렇게 크게 3개의 챕터로 크게 나눌 수 있을 거 같다. 이 과정 속 2,3번 부분에서 여러가지 많이 생각해볼 것들이 많았는데
- 좋은 객체지향 설계를 하기 위하여 어떻게 해야 할까?
- DI?(Dependency Injection)
- 역할과 구현을 나누면서 관심사를 분리하여 보자
- 각자의 역할에 집중할 수 있도록 기획자 역할을 만들자
이렇게 간단하게 글로만 적었지만 실제로 깊게까지 들어가보면 상당히 긴 글을 적을수도 있을만한 주제에 대해서 코드를 작성하면서 공부를 해보게 되었던 거 같다.
그리고 신기하였던 것이 IOC라는 단어하고 DI라는 것이 어찌보면 동일한 개념이라고 봐도 무관하다는 것이었다.
이게 약간 관계가 전에 네트워크 공부하다가 봤었던 URL과 URI처럼 IOC가 더 넓은 개념이고 그 안에 DI라는 개념이 들어가있다는 것을 알 수 있었다.
IoC(Inversion of Control) 일명 : 제어의 역전
프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)라고 한다.
DI(Dependency Injection) : 의존관계 주입
근데 위에서 왜 비슷하다라는 얘기를 했냐면 이게 프로그램의 제어 흐름을 외부로 제어할 수 있도록 하는 것이 결론적으로 DI를 하는 이유기 때문이다. 이게 보니까 IoC가 너무 개념적으로 넓다 보니까 의존관계에 더 초점을 맞추기 위한 것이라고 한다.
프레임워크 vs 라이브러리
- 프레임워크는 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다.(Junit)
- 반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.
정적에서 동적으로
이때까지 그림들로 봤던 것처럼 만약 정적이었다면 내가 어떤 할인 정책을 적용하려고 하는데 내가 눈으로 봐도 이런 의존관계라던지를 확인 할 수 있을 것이다.
그러나! 이제 할인 정책들을 변경을 해야하는 상황속 어떤 정책들이 올 지 모르는 상황이라면? 동적인 의존 관계로 당연히 넘어가야한다. 그래서 그냥 우리는 역할만 알 뿐이지 어떠한 정책들이 오는 것이 몰라도 알아서 동작될 수 있도록 밖에서 의존관계도 주입하여주고 한다.
결론
여러가지를 많이 알게 되는 챕터이자 알게 된다? 라는 말보다 경험을 하면서 이렇게 겪다보니까 괜히 이런 법칙들이 생긴 것이 아니구나라는 걸 많이 느끼게 되었던 거 같다.
출처
