스프링 핵심원리 기본편3 - AppConfig 리팩터링
안녕하세요 오늘의 강의도 정리해 보도록 하겠습니다.
전 수업에 만들었던 AppConfig는 역할이 있고 역할에 따른 구현이 한눈에 딱 안 보이고 있습니다.
요번에는 이 역할들이 들어나게 하는 과정을 진행하도록 하겠습니다.
기존소스는 주석처리 하고 역할과 구현을 나눈 소스로 변경된 리팩터링 한 AppConfig 코드를 보여드리겠습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
package hello.core;
import hello.core.member.*;
import hello.core.order.*;
import hello.core.discount.*;
public class AppConfig {
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
private MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
public OrderService oderService() {
return new OrderServiceImpl(memberRepository(),discountPolicy());
}
public DiscountPolicy discountPolicy() {
return new FixDiscountPolicy();
}
// public MemberService memberService() {
// return new MemberServiceImpl(new MemoryMemberRepository());
//}
//public OrderService oderService() {
// return new OrderServiceImpl(new MemoryMemberRepository(),new FixDiscountPolicy());// 요기에서 이제 할인 정책을 수정해 줄수 있다.
//}
}
|
cs |
위 소스를 보시면 역할과 구현이 정확하게 나누어져 있습니다. 예를 들어 MemberRepository 역할은 MemoryMemberRepository() 구현을 동착시킵니다.
이렇게 만들었을 때의 장점은 만약 메모리가 아닌 jdbc를 이용하고 싶다면 MemberRepository 역할의 구현 부분만 jdbc로 변경시켜주면 MemberService와 OrderService 한 번에변경되게 됩니다. DiscountPolicy 역시 마찬가지입니다..
또한 각 역할을 세우고 구현이 그 안에 들어가도록 만들어 놨기 때문에 코드의 가독성 또한 높아지게 됩니다. 그리고 중복도 제거가 됩니다.
새로운 구조와 할인 정책 적용
이제 fix가 아닌 rate로 할인 정책을 변경하려고 합니다.
이때 우리는 AppConfig만 변경해 주면 할인정책의 변경이 가능합니다.
1
2
3
4
|
public DiscountPolicy discountPolicy() {
// return new FixDiscountPolicy();
return new RateDiscountPolicy();
}
|
cs |
위와 같이 만들어 준다면 다른 변경 없이 AppConifg만 변경해 준다면 할인정책이 변경이 가능해집니다.
구성 역할을 담당하는 AppConfig 만 변경하면 사용영역 즉 impl의 코드는 아무것도 안 바꾸어 주어도 된다.
DIP와 OCP를 모두 만족하는 코드가 완성되었습니다.