[Spring] 객체 지향 원리 적용 - 새로운 할인 정책 개발

안녕하세요? 주니하랑입니다.

주니하랑은 앞에서 주문, 회원, 할인(고정 할인)에 대해서 순수 자바만을 활용해 열심히 공부를 했던 것이에요.

이번에는 김영한 강사님께서 할인에서 정률 할인을 하는 정책을 만드는 법에 대해서 알려주셨어요!

함께 공부 해 보실게요!

 

 

📋 목차

---

01. [Spring] 스프링 핵심 원리
02. [Spring] 좋은 객체 지향 설계의 5가지 원칙 (SOLID)
03. [Spring] 객체 지향 설계와 스프링   
04. [Spring] OCP와 DIP 고려하기
05. [Spring] 객체 지향 원리 적용 - 새로운 할인 정책 개발
06. [Spring] AppConfig 리팩터링    
07. [Spring] Ioc, DI Container  
08. [Spring] 스프링 컨테이너 생성  
09. [Spring] 싱글톤 컨테이너  
10. [Spring] Component Scan And Auto wired Start
11. [Spring] 의존관계 주입 방법    
12. [Spring] Bean Life Cycle Call Back
13. [Spring] Bean Scope

 

 

---

 

📌 새로운 할인 정책 개발

---

 

기존에 우리는 고정 할인 정책으로 코딩을 했던 것이에요. 하지만, 고객사의 정책 변경으로 정률 할인 정책을 도입해야 하는 것이에요.

 

         👉 RateDiscountPolicy 추가

 

출처: 인프런 - 김영한 강사 : 스프링 핵심 원리

 

 

         👉 RateDiscountPolicy 코드 추가

 

RateDiscountPolicy.java

 

이 Method는 DiscountPolicy를 구현하는 구현체이고, 구체화는 discount인 것이에요.

discount에서는 Member 객체와 구입가를 입력 받아 Member 등급이 VIP라면 구입가의 10을 곱한 뒤 나누기 100을 하여 10% 할인을 받도록 하여 반환하고, VIP가 아니라면 0을 반환하여 할인이 없도록 구현 한 것이에요.

 

         👉 Test 코드

 

반응형

 

 

 

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

위에 추가한 정률 할인 정책을 적용하려면 Client인 'OrderServiceImpl.java'의 코드 내용도 고쳐야 하는 것이에요.

 

출처: 인프런 - 김영한 강사 : 스프링 핵심 원리

 

위의 코드를 생각해보면 아래와 같은 문제점이 있음을 알 수 있답니다.

1. 개발자는 역할과 구현을 충실하게 분리했는가? Yes
2. 다형성도 활용하고, Interface와 구현 객체를 분리했는가? Yes
3. OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수 했는가?
   • 겉보기엔 그렇지만, 사실 No!

DIP: 주문 서비스 클라이언트(OrderServiceImpl)은 DiscountPolicy Interface에 의존하면서 DIP를 지키지 않았나요?

Class 의존 관계를 분석해 볼게요! 추상(Interface)뿐만 아니고, 구체(구현) Class도 의존(new RateDiscountPolicy)하고 있다는 사실 보이시나요?

• 추상(Interface) 의존 : DiscountPolicy
• 구체(구현) Class 의존 : FixDiscountPlicy, RateDiscountPolicy

OCP: 변경은 불가하고, 확장 할 수 있도록 했어요!

하지만, 지금 코드는 기능을 확장해서 변경하면, Client 코드에 영향을 줄 수 밖에 없는 것이에요. 때문에 OCP도 위반이랍니다!

 

그렇다면 왜? Client 코드에 변경을 해야 하는 것일까요? 다음은 Class Diagram인 것이에요.

 

         👉 기대한 의존관계

 

우리는 지금까지 단순히 DiscountPolicy 즉, 인터페이스만 의존한다고 생각했었어요! 하.지.만

 

 

         👉 실제 의존관계

 

 

자세히 보면 Client인 'OrderServiceImpl'이 'DiscountPolicy'와 'FixDiscountPolicy'를 모두 의존하고 있는 것을 확인 할 수 있는 것이에요. 즉, 구체 Class도 함께 의존하기 때문에 이것은 DIP 위반이랍니다!

 

이렇게 되면 'FixDiscountPolicy'를 'RateDiscountPolicy'로 변경하는 순간 'OrderServiceImpl'의 코드도 변경이 되어야 하기 때문에 OCP 또한 위반 인 것이에요.

 

우리는 DIP 위반을 해결하기 위해 추상(Interface)에만 의존하도록 변경해야 하는 것이에요.

 

 

         👉 Interface만 의존하도록 코드 변경

 

 

위와 같이 변경을 하게 되면 어떤 문제가 있을까요? 구현체가 없기 때문에 실행이 되지 않는 문제가 발생하는 것이에요.

그래서 실제 실행을 하면 NPE(Null Point Exception)이 발생하는 것이에요.

 

이 문제를 해결하기 위해 어떤 다른 곳에서 Client인 'OrderServiceImpl'에 'DiscountPolicy'의 구현 객체를 대신 생성하고, 주입해주어야 하는 것이에요.

 

 

 

 

    📍관심사의 분리

 

자! Application을 하나의 공연이라 생각해 볼게요! 각각의 Interface를 배역(배우의 역할)이라고 가정하고, 구현체를 각각의 배우들이라고 가정할 때 실제 배역에 맞는 배우를 선택하는 것은 누가 해야 될까요?

만약 로미오와 줄리엣 공연을 가정하면 로미오 역할과 줄리엣 역할을 누가 할지는 배우들이 정하는 것이 아니에요.

우리가 기존에 작성했던 코드는 마치 로미오 역할(Interface)를 하는 배우(구현체)에게 줄리엣 역할을 할 배우를 구해오라고 하는 것과 같은 이치인 것이에요. 그렇게 되면 로미오 역할의 배우는 공연도 해야 하고, 배우도 찾아야 하고, 업무에 과부하가 걸릴 것이에요.

 

따라서 배우는 본인의 역할인 연기에만 집중하게 해야 하는 것이에요.

그리고, 어떤 상대 배우가 나타나더라도 본연의 연기가 가능해야 하는 것이에요.

공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 찾는 것은 공연 기획자라는 역할이 나와야 하는 것이에요.

코드에서도 공연 기획자 같은 것을 만들고, 배우와 공연 기획자의 책임을 확실히 분리하면 되는 것이에요.

 

 

 

         👉 AppConfig

 

 

위의 Class는 Application의 실제 동작에 필요한 구현 객체를 생성하는 역할인 것이에요. 즉, 배우를 섭외하는 일이지요.

• MemberServiceImpl
• MemoryMemberRepository
• OrderServiceImpl
• FixDiscountPolicy

AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결) 해 주는 것이에요.

'MemberServiceImpl' -> 'MemoryMemberRepository'

'OrderServiceImpl' -> 'MemoryMemberRepository', 'FixDiscountPolicy'

 

 

 

 

         👉 MemberServiceImpl - 생성자 주입

 

설계를 변경하므로, 'MemberServiceImpl'은 'MemoryMemberRepository'를 의존하지 않게 된 것이에요.

다만, 'MemberRepository'라는 Interface만 의존하게 된 것이에요.

'MemberServiceImpl' 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없는 것이에요.

'MemberServiceImpl'의 생성자를 통해 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정되기 때문이죠.

'MemberServiceImpl'은 이제부터 의존관계에 대한 고민은 외부에 맡기고, 자신의 일인 실행에만 집중하면 되는 것이에요.

 

         👉 Class Diagram

 

객체 생성과 연결은 'AppConfig'가 담당하는 것이에요.

DIP 완성 : 'MemberServiceImpl'은 'MemberRepository'인 추상에만 의존하면 되는 것이에요. 이제 구체 Class를 몰라도 되요!

관심사의 분리 : 객체를 생성하고, 연결하는 역할과 실행하는 역할이 명확하게 분리된 것이에요.

 

 

 

         👉 회원 객체 인스턴스 Diagrame

 

 

'appConfig' 객체는 'memoryMemberRepository' 객체를 생성하고, 그 참조값을 'memberServiceImpl'을 생성하면서 생성자로 전달하는 것이에요.

Client인 'memberServiceImpl' 입장에서 보면 의존 관계를 마치 외부에서 주입해주는 것 같다고 하여 DI(Dependency Injection) 즉, 의존관계 주입 혹은 의존성 주입이라고 하는 것이에요.

 

 

         👉 OrderServiceImpl - 생성자 주입

 

 

필드(17번째 줄)을 보면 이제 더 이상 OrderServiceImpl은 FixDiscountPolicy를 의존하지 않는 것이에요.

interface인 추상 DiscountPolicy에만 의존하고 있답니다!

OrderServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지 (주입될지) 알 수 없는 것이에요.

OrderServiceImpl의 생성자를 통해 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정 한답니다!

이로써 OrderServiceImpl에는 MemoryMemberRepository, FixDiscountPolicy 객체의 의존관계가 주입 되는 것이에요.

 

 

         👉 사용 Class - MemberApp(Main())

 

 

 

 

         👉 사용 Class - OrderApp(Main())

 

 

         👉 Test 코드 수정 

 

 

 

 

@BeforEach : Test Code에서 각 Test 실행 전 먼저 호출되도록 하는 것으로, Test가 N개이면 N번 실행

 

 

 

출처 : 인프런 - 김영한 강사님의 스프링 핵심 원리 강의

이 글은 강의 내용과 강의 자료를 바탕으로 '주니하랑'이 이해하기 쉽기 위해 작성한 내용 임을 알려드립니다.

 

 

---

 

 

 

주니하랑의 글이 마음에 드셨나요? 구독과 공감! 그리고, 댓글 그리고 방명록은 주니하랑에게 많은 힘이 됩니다