관심사의 분리

관심사의 분리

 

 아래 코드는 구현부에서 FixDisCountPolicy(고정 할인) -> RateDisCountPolicy(비율 할인)으로 정책을 변경하려고 할 때 SOLID원칙을 위반하는 경우이다. 설정부와 구현부로 관심사를 분리하여 SOLID원칙을 만족시켜 보자.

public class OrderServiceImpl implements OrderService {

	private final MemberRepository memberRepository = new MemoryMemberRepository();
	//private final DisCountPolicy disCountPolicy = new FixDisCountPolicy();
	private final DisCountPolicy disCountPolicy = new RateDisCountPolicy();

	...

}

다음과 같은 상황은 할인 정책을 fix에서 rate로 바꾸려고 하는 상황이다.

discountPolicy라는 인터페이스를 사용해서 역할과 구현을 나누려고 했지만, fix → rate로 로직을 변경하는 순간에 코드수정이 필요해진다(DIP 원칙 위반)

해달 클래스는 직접 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있다.단일 책임 원칙 (SRP) 위반

 

AppConfig 등장

구현 객체를 생성하고 연결하는 클래스

public class AppConfig {

	public MemberService memberService() {
		return MemberServiceImple(new MemoryMemberService());
	}

	public OrderService orderService() {
		return OrderServiceImple(new MemoryMemberService(), new FixDiscountService());
	}

}

위와 같이 외부에서 설정해 줄 수 있다.

구현체에서는 코드의 변경이 필요 없어지고, 구현부에만 집중할 수 있다.

객체를 생성하고 연결하는 역할과 실행하는 역할이 명확이 분리된다.(DIP, SRP 완성)

다시 말해, 책임이 명확해진다.

 

AppConfig 리팩터링

public class AppConfig {

	public MemberService memberService() {
		return new MemberServiceImple(memberRepository());
	}

	public OrderService orderService() {
		return new OrderServiceImple(
        	memberRepository(), discountPolicy());
	}

	public MemberRepository memberRepository() {
		return new MemoryMemberService();
	}

	public DiscountPolicy discountPolicy() {
		return new FixDiscountService();
	}

}

역할과 구현에 대한 게 한눈에 들어오도록 수정, 중복 제거

 

 

좋은 객체 지향 설계 5가지 원칙 - https://mildwpaper.tistory.com/21

출처 - https://www.inflearn.com/course/스프링-핵심-원리-기본편/dashboard