public class AppConfig {
public MemberService memberService() {
return new MemberServiceImpl(new MemoryMemberRepository());
}
public OrderService orderService() {
return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
}
}
public class MemberServiceImpl implements MemberService {
private final MemberRepository memberRepository;
public MemberServiceImpl(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
}
public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
this.memberRepository = memberRepository;
this.discountPolicy = discountPolicy;
}
}
이제 MemberServiceImpl은 MemoryMemberRepository를 의존하지 않는다. 단지 MemberRepository 인터페이스만 의존한다.
MemberServiceImpl은 생성자를 통해 어떤 구현 객체가 주입될 지 알 수 없다. 오직 AppConfig라는 외부에 의해서 결정된다. MemberServiceImpl은 이제 의존 관계에 대한 고민을 외부에 맡기고 실행에만 집중하면 된다.
클래스 다이어그램
MemberServiceImpl이 MemberService를 구현하고 MemberRepository에 의존하는 건 동일하다. 대신 AppConfig 가 MemoryMemberRepository를 생성하고 연결해준다.
DIP가 지켜진다.
MemberServiceImpl은 MemberRepository라는 추상에만 의존하면 된다.
관심사의 분리가 이루어졌다.
객체를 생성하고 연결하는 역할과 실행하는 역할이 명확이 분리되었다.
회원 객체 인스턴스 다이어그램
AppConfig 객체는 MemoryMemberRepository 객체를 생성하고 그 참조값을 MemberServiceImpl을 생성하는 과정에서 생성자로 전달한다.
클라이언트인 MemberServiceImpl 입장에서 보면 의존 관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 즉, 의존 관계 주입이라고 한다.
public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
this.memberRepository = memberRepository;
this.discountPolicy = discountPolicy;
}
}
설계를 변경한 후로는 OrderServiceImpl이 FixDiscountPolicy를 의존하지 않는다. DiscountPolicy 인터페이스만 의존할 뿐이다.
OrderServiceImpl 입장에선 생성자를 통해 어떤 구현 객체를 주입받을 지 알 수 없다. 오직 AppConfig에서 결정한다. OrderServiceImpl은 실행에만 집중하면 된다.
public class MemberApp {
public static void main(String[] args) {
AppConfig appConfig = new AppConfig();
MemberService memberService = appConfig.memberService();
Member member = new Member(1L, "memberA", Grade.VIP);
memberService.join(member);
Member findMember = memberService.findMember(1L);
System.out.println("new member = " + member.getName());
System.out.println("findMember = " + findMember.getName());
}
}
public class OrderApp {
public static void main(String[] args) {
AppConfig appConfig = new AppConfig();
MemberService memberService = appConfig.memberService();
OrderService orderService = appConfig.orderService();
Long memberId = 1L;
Member member = new Member(memberId, "memberA", Grade.VIP);
memberService.join(member);
Order order = orderService.createOrder(memberId, "itemA", 10000);
System.out.println("order = " + order);
System.out.println("order.calculatePrice() = " + order.calculatePrice());
}
}
public class MemberServiceTest {
MemberService memberService;
@BeforeEach
void beforeEach() {
AppConfig appConfig = new AppConfig();
memberService = appConfig.memberService();
}
}
public class OrderServiceTest {
MemberService memberService;
OrderService orderService;
@BeforeEach
void beforeEach() {
AppConfig appConfig = new AppConfig();
memberService = appConfig.memberService();
orderService = appConfig.orderService();
}
}
메인 메서드와 테스트 코드도 AppConfig에서 받아오도록 수정한다.
정리
AppConfig를 통해 관심사를 확실하게 분리했다.
배역에 맞는 배우를 선택하는 공연 기획자처럼 애플리케이션이 어떻게 동작할지 전체 구성을 책임진다.
각 클래스들은 기능을 실행하는 책임만 지면 된다.
AppConfig 리팩토링
역할이 어떤 게 있고 그 역할이 어떤 걸 구현하는지 한 눈에 보이는 게 중요한데 현재의 AppConfig로는 그게 보이질 않는다.
public class AppConfig {
// 메서드 명을 보는 순간 역할이 드러난다.
// memberService에서는 memberServiceImpl을 쓸 것이다.
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
// memberRepository는 memory로 쓸 것이다.
// 그래서 나중에 다른 repository를 쓰려면 이 코드만 바꾸면 된다.
private MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
public OrderService orderService() {
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
private DiscountPolicy discountPolicy() {
return new FixDiscountPolicy();
}
}
이제 각 역할과 구현 클래스가 한 눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되었는지 빠르게 파악할 수 있다.
public class AppConfig {
...
public OrderService orderService() {
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
private DiscountPolicy discountPolicy() {
// 이 부분만 변경하면 된다.
// return new FixDiscountPolicy();
return new RateDiscountPolicy();
}
}
AppConfig에서 할인 정책 역할을 담당하는 구현을 FixDiscountPolicy에서 RateDiscountPolicy 객체로 변경했다. 할인 정책을 변경해도 구성 역할을 담당하는 AppConfig만 건드리면 된다. 사용 영역은 하나도 변경되지 않는다.
구성 영역은 당연히 변경된다. 공연 기획자는 공연 참여자를 다 알아야 하듯, AppConfig는 구현 객체를 모두 알아야 한다.
