저번 게시글에 이어서 이번 게시글에서는 SOLID 원칙중 SRP, OCP, DIP 를 적용해서 기존 코드를 바꿔보려고 한다.
기존 코드와 그 문제점
DiscountPolicy의 구현체로 FixDiscountPolicy는 고정된 할인을 해주는 정책이고 RateDiscountPolicy 는 10%의 할인을 해주는 정책이다.
우리가 기대했던 의존관계는 위와 같이 OrderServiceImpl 이라는 주문서비스 클라이언트가 DiscountPolicy 인터페이스에만 의존하는 것 이었다.
public class OrderServiceImpl implements OrderService {
private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
//private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}하지만 실제 코드를 살펴보면 우리가 할인 정책을 바꾸려면 클라이언트의 코드를 고쳐야 된다. OrderServiceImpl은 DiscountPolicty 인터페이스와 FixDiscountPolicy 라는 구현체를 동시에 의존하고 있다. ( 아래 그림)
→ DIP 위반 : 인터페이스 뿐만 아니라 구체(구현) 클래스에 의존한다.
→ OCP 위반 : 할인 정책을 추가(기능 확장) 하면 클라이언트 코드에 영향을 준다.
→ SRP 위반 : 인터페이스에 구현체를 연결시킴 + 주문서비스 기능 두가지 기능을 가진다.
해결 방법
DIP를 위반 하지 않게 인터페이스(추상) 에만 의존하도록 코드를 바꿔준다.
인터페이스만 의존하도록 코드 변경
public class OrderServiceImpl implements OrderService {
//private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
private DiscountPolicy discountPolicy;
}인터페이스에만 의존하도록 코드를 변경했더니 구현체가 없어서 코드를 실행 할 수 없다.
→ 이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy 의 구현 객체를 대신 생성하고 주입 해주어야 한다.
관심사의 분리
애플리케이션을 하나의 공연이라 생각하고 각각의 인터페이스를 배역이라 하자.
그런데! 실제 배역을 맡는 배우를 선택하는 것은 누가 하는가?
로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할지 줄리엣 역할을 누가 할지는 배우들이 정하는게 아니다.
이전 코드는 마치 로미오 역할(인터페이스)을 하는 레오나르도 디카프리오(구현체)가 줄리엣 역할(인터페이스)을 하는 여자 주인공(구현체)을 직접 초빙하는 것과 같다.
디카프리오는 공연도 해야하고 동시에 여자 주인공도 공연에 직접 초빙해야 하는 다양한 책임 을 가지고 있다.
관심사를 분리하자
배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다.
디카프리오는 어떤 여자 주인공이 선택되더라도 똑같이 공연을 할 수 있어야 한다.
공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 지정하는 책임을 담당하는 별도의 공연 기획자 가 나올시점이다.
공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실히 분리하자.
AppConfig
애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들자. (공연기획자)
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();
}
}AppConfig 는 구현 객체를 생성하고 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.
이제 MemberServiceImpl 와 OrderServiceImpl 의 생성자를 만들어주자.
public class MemberServiceImpl implements MemberService {
private final MemberRepository memberRepository;
public MemberServiceImpl(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
public void join(Member member) {
memberRepository.save(member);
}
public Member findMember(Long memberId) {
return memberRepository.findById(memberId);
}
}이제 MemberServiceImpl 은 MemberRepository 인터페이스에만 의존하며 어떤 구현체를 주입할지는 외부(Appconfig)를 통해서 결정된다.
의존관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 된다.
→ DIP 완성 : MemberServiceImpl은 이제 구현체가 아닌 인터페이스만 의존한다.
→ 관심사의 분리 : 객체의 생성과 연결하는 역할과 실행하는 역할이 분리되었다.
→ DI(의존성주입) : 클라이언트인 memberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다
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;
}
@Override
public Order createOrder(Long memberId, String itemName, int itemPrice) {
Member member = memberRepository.findById(memberId);
int discountPrice = discountPolicy.discount(member, itemPrice);
return new Order(memberId, itemName, itemPrice, discountPrice);
}
}정리
이제 FixDiscountPolicy 에서 RateDiscountPolicy 로 변경해도 구성영역만 변경되고 사용영역은 전혀 영향을 받지 않는다.
SRP(단일 책임 원칙)
기존 클라이언트 코드는 구현체를 생성하고 연결하고 실행하는 다양한 책임을 가졌다.
→ SRP를 따르면서 관심사를 분리하여 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당하고 클라이언트 객체는 실행하는 책임만 담당한다.
DIP(의존관계 역전 원칙)
기존 코드는 추상화(인터페이스) 와 구체화(구현 클래스) 를 동시에 의존 했다.
→ 클라이언트 코드가 인터페이스에만 의존 하도록 코드를 변경하고 AppConfig 가 객체 인스터스를 생성하여 클라이언트 코드에 의존관계를 주입하였다.
OCP
AppConfig가 의존관계를 FixDiscountPolicy RateDiscountPolicy 로 변경해서 클라이언트 코드에 주입하므로 클라이언트 코드는 변경하지 않아도 된다.
→ 애플리케이션을 사용 영역과 구성 영역으로 나누어서 요소를 새롭게 확장해도 사용영역의 변경은 닫혀있다.
참고
이 글은 인프런 - 김영한님의 스프링 핵심원리 기본편 을 참고하여 작성하였습니다.
