[Spring] 스프링 예제 - 주문과 할인2 (SRP, OCP, DIP 적용)

https://wngml56.tistory.com/217

[Spring] 스프링 예제 - 주문과 할인1 (OCP와 DIP 미 적용)

와 이어지는 글입니다.

 

---

목차

 

할인 정책의 변경

서비스 오픈 직전, 갑자기 기획자가 기존의 고정 할인 정책에서 정률 % 할인으로 변경을 하고 싶다고 요청을 해왔습니다.

• 기획자 : 할인 정책을 지금처럼 고정 금액 할인 정책이 아니라, 더 합리적이게 주문 금액당 할인하는 정률 % 할인으로 변경하고 싶어요. 
  예를 들어서 기존 정책은 VIP가 만원을 주문하든 2만원을 주문하든 항상 1000원만을 할인해줬는데, 이번엔 10%로 지정해서 만원을 주문하면 1000원을, 2만원을 주문하면 2000원을 할인하도록 바꿔주세요.
• 개발자 : 객체 지향 설계 원칙을 준수하면서 개발해서 가능합니다.
• 애자일 소프트웨어 개발 선언 : "계획에 따르기보다 변화에 대응하기를" 

 

정률 할인 정책 추가

RateDiscountPolicy

public class RateDiscountPolicy implements DiscountPolicy {

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

테스트 (성공) 

public class RateDiscountPolicyTest {

    RateDiscountPolicy discountPolicy = new RateDiscountPolicy();

    @Test
    @DisplayName("VIP는 10% 할인이 적용되어야 한다.")
    void vip_o() {
        //given
        Member member = new Member(1L, "memberVIP", Grade.VIP);

        //when
        int discount = discountPolicy.discount(member, 10000);

        //then
        assertThat(discount).isEqualTo(1000);
    }

    @Test
    @DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다.")
    void vip_x() {
        //given
        Member member = new Member(2L, "memberBASIC", Grade.BASIC);

        //when
        int discount = discountPolicy.discount(member, 10000);
        
        //then
        assertThat(discount).isEqualTo(0);
    }
}

 

 

문제점: 고정할인 정책에서 정률 할인 정책으로 변경

할인 정책을 FixDiscountPolicy에서 새로운 DisCountPolicy로 교체하기 위해선, 클라이언트인 OrderServiceImpl 코드를 다음과 같이 수정해야 합니다. 

 

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

• 클라이언트의 수정을 줄이고자 역할과 구현을 분리했다.  → OK
• 다형성을 활용하고, 인터페이스와 구현 객체를 분리했다. → OK
• 하지만, OCP와 DIP 원칙을 준수하지 않았습니다.
• DIP : "추상화에 의존해야지, 구체화에 의존하면 안된다"
  • 현재 코드는 추상화(인터페이스) 뿐만 아니라, 구체화에도 의존하고 있으므로 위배됩니다.
  • 추상(인터페이스) : DiscountPolicy
  • 구체(구현) 클래스 : FixDiscountPolicy, RateDiscountPolicy
• OCP : "확장에는 열려있으나, 변경에는 닫혀 있어야 한다."
  • 클라이언트의 수정(변경)없이 기능을 교체하거나 확장할 수 없습니다. 따라서 OCP 원칙을 위배합니다.

 

기대했던 의존관계

클라이언트가 인터페이스를 의존한다.

 

현재 작성된 의존관계

인터페이스와 구현체를 동시에 의존한다. (DIP 위반)

 

 

문제 발생 : 정책을 변경

클라이언트가 FixDiscountPolicy에도 의존하고 있기 때문에, RateDiscountPolicy로 교체할 때 클라이언트도 수정해야 한다. (OCP 위반)

 

해결책: 의존관계 주입

1. 인터페이스에만 의존하도록 다음과 같이 코드를 수정합니다.

클라이언트가 인터페이스에만 의존한다.

public class OrderServiceImpl implements OrderService {

//    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
    private DiscountPolicy discountPolicy;

}

※ 만약, 이대로 실행을 한다면 NPE(Null Pointer Exception)이 발생합니다. 

 

 

2. FixDiscountPolicy와 RateDiscountPolicy 둘 중 어떤 구현체를 클라이언트가 선택할지는 다른 누군가가 구현체를 생성하고 주입해줘야 합니다. → AppConfig 등장, 스프링의 역할

 

 

AppConfig 등장

애플리케이션의 전체 동작 방식을 구성(Config)하기 위해, 구현 객체를 생성하고 연결하는 책임을 지는 별도의 설정 클래스입니다. 

 

AppConfig

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 → MemoryMemerRepository, FixDiscountPolicy

 

MemberServiceImpl - 생성자 주입

public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

• 설계 변경으로 MemberServiceIml은 MemoryMemberRepository를 의존하지 않고, 단지 MemberRepository 인터페이스만 의존합니다. 
• MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 주입될지 알 수 없습니다.
• MeberServiceImpl 의 생성자를 통해서 어떤 객체를 주입할지는 오로지 외부(AppConfig)에서 결정됩니다. 
• MemberServiceIml은 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 됩니다. (관심사의 분리, SRP 원칙)

 

클래스 다이어그램

• DIP 완성 : MemberServicImpl은 MemberRepository인 추상에만 의존한다.
• 관심사의 분리 : 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었다.

 

회원 객체 인스턴스 다이어그램

• appConfig 객체는 memoryMemberRepository 객체를 생성하고 그 참조값을 memberServiceImpl 을 생성하면서 전달합니다. 
• 클라이언트인 memberServiceImpl 입장에서 보면 의존 관계를 마치 외부에서 주입해주는 것과 같다고 해서 DI(Dependency Injection) 우리말로 의존관계 주입 또는 의존성 주입이라고 합니다.

 

OrderServiceImpl - 생성자 주입

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);
    }
}

테스트 코드 수정

public class MemberServiceTest {

    MemberService memberService;
    
    @BeforeEach
    public void beforeEach() {
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
    }
}

• 테스트 코드에서 @BeforeEach는 각 테스트를 실행하기 전에 호출됩니다.

 

public class OrderServiceTest {

    MemberService memberService;
    OrderService orderService;
    
    @BeforeEach
    public void beforeEach() {
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
        orderService = appConfig.orderService();
    }
}

 

 

AppConfig 리팩토링

현재 AppConfig를 보면 중복이 있으며, 역할에 따른 구현이 잘 보이지 않습니다.

 

기대하는 그림

리팩토링 전

public class AppConfig {

    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
    }

    public OrderService orderService() {
        return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
    }
}

리팩토링 후

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();
    }
}

 

 

새로운 구조와 할인 정책 적용

처음으로 돌아가 정액 할인 정책을 정률 할인 정책으로 변경해봅시다.

FixDiscountPolicy → RateDiscountPolicy

 

그림 - 사용, 구성의 분리

 

 

그림 - 할인 정책의 변경

FixDiscountPolicy를 RateDiscountPolicy로 변경할 땐, 구성 영역인 AppConfig만 영향을 받고, 사용 영역은 전혀 영향을 받지 않습니다.

 

AppConfing - 할인 정책 변경

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();
        return new RateDiscountPolicy();
    }
}

 

 

좋은 객체 지향 설계 5가지 원칙

SRP, DIP, OCP를 적용할 수 있게 되었습니다. 

 

SRP 단일 책임 원칙

한 클래스는 하나의 책임만 가져야 한다.

• 객체를 생성하고 연결하는 책임을 AppConfig로 분리했다.
• 클라이언트 객체는 실행만을 담당한다.

 

DIP 의존관계 역전 원칙

추상화에 의존해야지, 구체화에 의존하면 안 된다.

• 새로운 할인 정책으로 교체하려 할때, 클라이언트 코드도 변경해야 하는 문제점이 생겼다.
• 클라이언트는 인터페이스 뿐만 아니라 구현체에도 의존했기 때문이다.
• AppConfig가 객체를 생성하고 의존관계를 주입해줌으로써 클라이언트 코드는 인터페이스에만 의존할 수 있게 되었다. 

 

OCP 계방-폐쇄 원칙

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

• 새로운 할인 정책으로 교체하려 할때, 클라이언트 코드도 변경해야 하는 문제점이 생겼다.
• AppConfig가 객체를 생성하고 의존관계를 주입해줌으로써, 기능 확장에는 열려 있지만 클라이언트 코드는 수정을 하지 않아도 되므로 변경에는 닫혀 있다. 

 

프레임워크 vs 라이브러리

• 내가 작성한 코드를 제어하고, 대신 실행한다면 프레임워크입니다. (ex) JUnit)
• 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리입니다.

 

의존관계 주입 (DI)

OrderServiceImpl은 DiscountPolicy 인터페이스에 의존합니다. 실제 어떤 구현 객체가 사용될지는 모릅니다.

의존관계는 정적인 클래스의 의존관계와 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생각해야 합니다.

 

정적인 클래스 의존관계

• 클래스가 사용하는 import 코드만 보고 의존 관계를 쉽게 판단할 수 있습니다.
• 정적인 의존관계는 애플리케이션을 실행하지 않아도 분석할 수 있습니다.
• 아래의 클래스 다이어그램을 보면 OrderServiceImpl이 MemberRepository와 DiscountPolicy를 의존한다는 것을 있습니다.
• 그런데, 이러한 클래스 의존 관계만으로는 실제 어떤 객체가 OrderServiceImpl에 주입이 될지 알 수 없습니다.

클래스 다이어그램

 

 

동적인 객체 인스턴스 의존 관계

애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계입니다.

 

객체 다이어그램

• 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것을 의존관계 주입이라 합니다.
• 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있습니다.

 

IoC 컨테이너, DI 컨테이너?

• AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 IoC 컨테이너 또는 DI 컨테이너라 합니다.
• 의존관계 주입에 초점을 맞추어, 최근에는 주로 DI 컨테이너라 합니다.
  (IoC는 여러군데에서 쓰입니다. 예를 들어 JUnit에서도 쓰입니다. 이처럼 스프링만 DI 컨테이너라고 하는 것은 아닙니다.)
• 또는 어셈블러, 오브젝트 팩토리 등으로 불리기도 합니다. 

 

스프링으로 전환하기

지금까지 순수한 자바 코드만으로 DI를 적용했습니다. 이제 스프링을 사용해봅시다.

AppConfig - 스프링 기반으로 변경

• 설정을 구성한다는 뜻의 @Configuration 애노테이션을 붙여줍니다.
• 각 메서드에 @Bean 애노테이션을 붙여 스프링 컨테이너에 스프링 빈으로 등록합니다. 

@Configuration
public class AppConfig {
    
    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

테스트 - MemberApp

public class MemberApp {
    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig();
//        MemberService memberService = appConfig.memberService();
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        
        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

public class OrderApp {
    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig();
//        MemberService memberService = appConfig.memberService();
//        OrderService orderService = appConfig.orderService();
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);

        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);
        System.out.println("order.calculatePrice = " + order.calculatePrice());
    }
}

 

실행 결과
두 클래스를 실행하면 스프링 관련 로그가 몇 줄 실행되며, 기존과 동일한 결과가 출력됩니다. 

 

스프링 컨테이너

• ApplicationContext를 스프링 컨테이너라고 합니다.
• 기존 코드에선 개발자가 AppConfig를 사용해 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 이용합니다.
• 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정(구성) 정보로 사용합니다. 여기서 @Bean 이라 적힌 메서드의 명을 스프링 빈의 이름으로 사용합니다.
  (ex) memberService, orderService)
• 이전에는 개발자가 필요한 객체를 AppConfig를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해 필요한 스프링 빈(객체)를 찾아서 씁니다.
  스프링 빈은 applicationContext.getBean() 메서드를 사용해 찾을 수 있습니다.

 

기존보다 스프링 컨테이너를 씀으로써 코드가 더 복잡해진 것 같습니다.

그렇다면, 스프링 컨테이너를 사용함으로써 어떤 장점이 있을까요?

다음 글에서 작성하도록 하겠습니다.

 

---

 

출처 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 - 인프런 | 강의