[Spring] 객체 지향 원리 적용

Narcoker·2023년 8월 12일
Spring

Spring

목록 보기
3/20

새로운 할인 정책 개발

어떤 쇼핑몰 사이트가 있다고 가정하자

이 사이트의 회원들은 2개의 등급이 있다.

  • Basic
  • VIP

구매를 할때 VIP 회원은 고정 금액인 1000원을 할인해주는 정책이 존재했다.

이후 이 쇼핑몰에서 구매금액에 10%를 할인해주는 새로운 할인 정책을 적용하려고 한다.

새로운 할인 정책 적용과 문제점

RateDiscountPolicy 코드 추가

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;
public class RateDiscountPolicy implements DiscountPolicy {

@Override
private int discountPercent = 10; //10% 할인 
     public int discount(Member member, int price) {
         if (member.getGrade() == Grade.VIP) {
             return price * discountPercent /  100;
         } else {
             return 0;
		} 
	}
}

문제점

할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야한다.

수정 전

 public class OrderServiceImpl implements OrderService {
 	// 1000원 고정 할인 정책
 	private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
 }

수정 후

 public class OrderServiceImpl implements OrderService {
     // 10% 할인 정책
     private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
 }

역할(OrderService) 와 구현(OrderServiceImple) 을 충실하게 분리했다.
다형성도 활용하고, 인터 페이그 와 구현 객체를 분리했다.

단, OCP(개방-폐쇄 원칙)과 DIP(의존관계 역전 원칙)을 준수한 것 같지만 사실은 아니다.

DIP
프로그래머는 추상화에 의존해야하지, 구체화에 의존하면 안된다.
즉, 구현 클래스에 의존하지말고, 인터페이스에 의존해라는 뜻이다.

클래스 의존관계를 분석해보면 추상(인터페이스) 뿜만 아니라 구체(구현) 클래스에도 의존하고있다.

  • 추상(인터페이스) 클래스 의존 : DiscountPolicy
  • 구체(구현) 클래스 의존: FixDiscountPolicy, RateDiscountPolicy

OrderServiceImpl이 DiscountPolicy 인터페이스 뿐만 아니라
FixDisDountPolicy 인 구체 클래스도 함께 의존하고 있다.

OCP
소프트웨어의 요소는 확장에서는 열려있으나 변경에는 닫혀있어야한다.

지금 코드는 기능을 확장해서 변경하면 클라이언트 코드를 수정 해야하므로 OCP를 위반한다.

문제를 해결하는 방법

클라이언트 코드인 OrderServiceImple 은 DiscountPolicy의 인터페이스 뿐만아니라
구체 클래스도 함께 의존한다.

따라서 현재는 구체 클래스를 변경할 때 클라이언트 코드도 함께 변경해야한다.
이런 구조로 인해서 DIP를 위반한다.

즉, 문제를 해결하기 위해서
DIP를 위반하지 않게, 인터페이스에만 의존하도록 의존관계를 변경하면 된다.

인터페이스에만 의존하도록 설계를 변경하자

변경 전

public class OrderServiceImpl implements OrderService {
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}

변경 후

public class OrderServiceImpl implements OrderService {
     private DiscountPolicy discountPolicy;
}

변경 후 코드로 바꿈으로써 인터페이스만 의존하도록 했다.

근데 구현체가 없는데 코드를 어떻게 실행할 수 있을까?
discountPolicy 에 구현체를 할당하지 않아서 코드를 실행해보면
null point exception이 발생한다.

이 문제를 해결하려면 누군가 가 클라이언트인 OrderServiceImple에
DiscountPolicy의 구현 객체를 대신 생성하고 주입해줘야한다.

관심사의 분리

즉, 역할에 구현체를 할당해줄, 책임자 같은 누군가의 새로운 등장이 필요하다.

AppConfig의 등장

책임자 역할인, 누군가 이다.
이 AppConfig는 구현 객체를 생성하고 연결하는 책임을 가지는 별도의 설정 클래스 이다.

package hello.core;

import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

 public class AppConfig {
     public MemberService memberService() {
         return new MemberServiceImpl(new MemoryMemberRepository());
	}
     public OrderService orderService() {
         return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
	}

AppConfig는 애플이케이션의 실제 동작에 필요한 구현 객체를 생성한다.

  • MemberServiceImpl
  • MemoryMemberRepository
  • OrderServiceImpl
  • FixDiscountPolicy

AppConfig는 생성한 객체 인스턴스 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.

  • MemberServiceImpl -> MemoryMemberRepository
  • OrderServiceImpl-> MemoryMemberRepository, FixDiscountPolicy

현재는 각 클래스에 생성자가 없다 따라서 Impl 클래스에 생성자를 만들어줘야한다.

package hello.core.member;

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은 MemoryMemberRepository를 의존하지 않게된다.
오로지 MemberService 인터페이스만 의존한다.

MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 주입될지 알 수 없다.
이는 오직 외부(AppConfig)에서 결정된다.

즉, MemberserviceImpl은 의존 관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 된다.


appConfig 객체는 memoryMemberRepository 객체를 생성하고
그 참조 값을 memberServiceImple을 생성하면서 생성자로 전달한다.

클라이언트인 memberServiceImpl 입장에서 보면
의존관계를 마치 외부에서 주입해주는 것 같다고 해서
DI(Dependency Injection) -> 의존관계 주입 또는 의존성 주입이라고 한다.

AppConfig 실행

이제 AppConfig 클래스를 사용해서 의존관계를 주입하고 실행해보자

MemberApp

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;

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("find Member = " + findMember.getName());
	}
}

OrderApp

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.order.Order;
import hello.core.order.OrderService;
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);
   }
}

AppConfig를 통해서 관심사를 확실하게 분리했다.
OrderServiceImpl 은 기능을 실행하는 책임만 지면 된다.

AppConfig 리팩토링

현재 AppConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 안보인다.

수정 전

package hello.core;

import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
}
    public OrderService orderService() {
        return new OrderServiceImpl(new MemoryMemberRepository(),new FixDiscountPolicy());
 	}
 }

수정 후

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {
    public MemberService memberService() { // MemberServiceImpl 생성 및 의존성 주입
        return new MemberServiceImpl(memberRepository());
	}

	public OrderService orderService() { // OrderServiceImpl 생성 및 의존성 주입
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
	}

    public MemberRepository memberRepository() { // memberRepository 생성
        return new MemoryMemberRepository();
	}

    public DiscountPolicy discountPolicy() { // discountPolicy 생성
        return new FixDiscountPolicy();
	}
}
  • new MemoryMemberRepository() 이 부분이 중복 제거되었다.
    이제 MemoryMemberRepository 를 다른 구현체로 변경할 때 한 부분만 변경하면 된다.
  • AppConfig 를 보면 역할과 구현 클래스가 한눈에 들어온다.
    애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다.

현재 할인 정책은 1000원 고정 할인 정책인데
10% 할인 정책으로 바꾸려면 AppConfig 만 수정하면 된다.

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

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 RateDiscountPolicy(); // 수정
	}
}

정리

  • 정액 할인 정책 정률% 할인 정책으로 변경
  • AppConfig의 등장으로 애플리케이션이 크게 사용 영역과,
    객체를 생성하고 구성(Configuration)하는 영역으 로 분리
  • 할인 정책을 변경해도 AppConfig가 있는 구성 영역만 변경하면 됨,
    사용 영역은 변경할 필요가 없다.
    물론 클라이언트 코드인 주문 서비스 코드도 변경하지 않음
profile
Narcoker
열정, 끈기, 집념의 Frontend Developer
이전 포스트

[Spring] 좋은 객체 지향 설계의 5가지 원칙(SOLID)

다음 포스트

[Spring] IoC, DI

0개의 댓글