김영한 강좌 예시
- 할인 정책을 위해선 회원 서비스 역할이 필요
Before
public class AppConfig {
public MemberService memberService() {
return new MemberServiceImpl(new MemoryMemberRepository());
}
public OrderService orderService() {
return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
}
}After
public class AppConfig {
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
public OrderService orderService() {
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
public DiscountPolicy discountPolicy() {
return new RateDiscountPolicy();AppConfig란?
- 애플리케이션의 실제 동작에 필요한 구현 객체 생성
- 위 예시에선 MemberServiceImpl, MemoryMemberRepository, OrderServiceImpl, RateDiscountPolicy라는 구현 객체를 생성한다.
작성시 고려할 점
1. 각각의 역할과 구현이 잘 드러나도록 작성한다.
위 다이어그램에 필요한 역할
1. 주문 서비스 역할
2. 회원 저장소 역할
3-1. 할인 정책 역할
3-2. 회원 서비스 역할
총 4개의 역할로 구성되어 있다. 이 역할들이 AppConfig 내에 잘 드러나도록 작성하는 것이 이후 관리하기 쉽다.
Before에는 회원 서비스 역할과 주문 서비스 역할만이 드러났고 다른 역할들은 찾기가 힘들다. 그렇기 때문에 할인정책 역할과 회원 저장소 역할은 무엇을 구현했는지 한눈에 보기 힘들다.
After에는 4개의 역할 모두 한눈에 보기 쉽게 작성이 되어있는 것을 확인할 수 있다. 또한, 각 역할마다 무엇을 구현하는지 정확하게 알 수 있다.
2. 중복되는 객체를 만들지 않는다.
자바에선 new를 통해 새로운 객체(인스턴스)를 생성하는데 다수의 역할에 해당 인스턴스가 필요하다고 매번 만드는 것이 아니라 하나 만든 것을 같이 사용하는 것이 옳다.
하지만 지금 배운 부분에서는 결국 두개의 다른 MemoryMemberRepository 객체를 사용하게 되는데... 추후 강의에서 설명이 나오니 간략하게 내용 추가할 예정(2022-05-07).
Before에서 주문 서비스 역할과 회원 서비스 역할은 모두 메모리 회원 저장소 객체를 만들어서 전해준다. 같은 일을 하는 객체를 new를 통해 두번 만든 것을 확인할 수 있다.
After에서 회원 저장소 역할을 만들어 MemoryMemberRepository객체를 생성하여 주입해준다. 결국 역할과 구현이 잘 드러내며 중복된 부분을 없앨 수 있게 되었다.
복습하며 다시 알게 된 부분
- AppConfig는 OrderService(예시) 인터페이스의 구현 객체인 OrderServiceImpl뿐이 아니라 해당 인터페이스의 다른 구현 객체를 생성하고 실행할 수도 있다.
- 클라이언트 == 요청; 서버 == 응답
- AppConfig에서 구현체 생성 및 연결을 해주므로, 사용 영역인 클라이언트 부분은 인터페이스에만 의존하면 된다.
- AppConfig의 주 목적은 관심사 영역 분리
- AppConfig는 전체 애플리케이션의 동작 방식의 구성
- 클라이언트는 자신의 역할을 실행하는 것에만 집중 -> 권한이 줄어들기 때문에 책임이 명확해짐
- 관심사 분리에도 장단점이 있기 때문에 상황에 맞게 사용해야 좋다
- 장점
- 높은 자유도
- 유지 보수 및 확장 용이
- 클라이언트 코드 수정보다 AppConfig를 통해 바꿀 수 있게 됨 (OCP)
- 단점
- 추상화 비용이 추가됨
- 그래서?
- 확장 가능성 있는 부분은 인터페이스를 구현하는 방식으로 개발
- 확장 가능성 없는 부분은 클래스로 구현하는 방식으로 개발
- 장점
