반응형
관심사의 분리
- 배우(구현체)는 본인의 배역(인터페이스) 구현에만 집중
- 특정 배우는 상대 배우가 누가 됐든 같은 역할을 수행해야한다.
- 배역에 어떤 배우를 섭외할 지, 공연 기획자가 필요하다
- 공연기획자를 만들고. 배우와 기획자의 책임을 분리하자
AppConfig : 실제 사용할 구현체를 지정
public class AppConfig {
public MemberService memberService() {
return new MemberServiceImpl(new MemoryMemberRepository());
}
public OrderService orderService() {
return new OrderServiceImpl(
new MemoryMemberRepository(),
new FixDiscountPolicy());
}
}
- appConfig 객체는 memoryMemberRepository 객체를 생성하고 그 참조값을 memberServiceImpl 을 생성하면서 생성자로 전달한다.
- 클라이언트인 memberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 우리말로 의존관계 주입 또는 의존성 주입이라 한다.
- 서비스 구현체는 비지니스 로직의 책임만 지면 된다.
AppConfig 리팩토링
중복을 제거하고, 역할과 구현을 명확히 분리
public class AppConfig {
public MemberService memberService() {
return new MemberServiceImpl(getMemberRepository());
}
private MemberRepository getMemberRepository() {
return new MemoryMemberRepository();
}
public OrderService orderService() {
return new OrderServiceImpl(getMemberRepository(), discountPolicy());
}
public DiscountPolicy discountPolicy() {
//return new FixDiscountPolicy();
return new RateDiscountPolicy();
}
}
AppConfig에서 구현체만 갈아끼면서 동작을 변경할 수 있다. (서비스 로직 변경 X)
728x90
반응형
'스프링' 카테고리의 다른 글
스프링 핵심 원리 - (7) (0) | 2022.08.05 |
---|---|
스프링 핵심 원리 - (6) (0) | 2022.08.04 |
스프링 핵심 원리 - (4) (0) | 2022.08.03 |
스프링 핵심 원리 - (3) (0) | 2022.08.03 |
스프링 핵심 원리 - (2) (0) | 2021.09.10 |
댓글