[Spring] OCP와 DIP 고려하기

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

오늘은 Spring의 객체 지향 설계에서 OCP원칙과 DIP를 좀 더 공부 해 보도록 하는 것이에요.

이 내용은 인프런 - 김영한 강사님의 스프링 핵심 원리를 공부하면서 정리 하였습니다.

이 강의에 대한 Code는 여기에 준비 해 둘게요!

 

📋 목차

---

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

 

 

 

---

 

 

📌 비즈니스 요구사항과 설계

---

1. 회원
   • 회원을 가입하고, 조회할 수 있다.
   • 회원은 일반과 VIP 두 가지 등급이 있다.
   • 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있으나, 어떤 DB를 쓸지 어떤 방식으로 Data를 처리할지 정해지지 않았다.
2. 주문과 할인 정책
   • 회원은 상품을 주문할 수 있다.
   • 회원 등급에 따라 할인 정책을 적용할 수 있다.
   • 할인 정책은 모든 VIP는 1,000원을 할인 해 주는 고정 금액 할인을 적용해달라고, 요청 받았다.
     (단, 나중에 정책은 변경 될 수 있다고 한다.)
   • 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을수도 있다.

 

위와 같은 내용으로 코딩을 하면서 이번 공부를 시작 해 보도록 할게요. 먼저, DB도 정해지지 않았고, 할인 정책 같은 경우는 오픈 직전까지 미루고 싶다고 해요! 그럼 도대체 개발을 하라는 걸까요? 말라는걸까요?

바로 이 때, 객체 지향적 프로그래밍을 한다면 그리고, DIP와 OCP 원칙을 지킨다면 이 문제는 걱정 거리가 아니랍니다!

 

이 문제를 해결하기 위해 Interface를 만들고, 구현체를 언제든지 갈아끼울 수 있도록 설계를 하면 되는 것이에요.

Interface는 역할! 구현체는 그 역할을 구현 하는 것!

 

💡 참고로 이번 공부에서는 Spring을 사용하지 않고, 오로지 순수 자바로만 공부하는 것이에요!

 

 

    📍회원 도메인 설계

• 회원 도메인 요구사항
  • 회원을 가입하고, 조회할 수 있다.
  • 회원은 일반과 VIP 두 가지 등급으로 나뉜다.
  • 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다.

 

 

         👉 회원 도메인 협력 관계

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

 

 

         👉 회원 클래스 다이어그램

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

 

 

         👉 회원 객체 다이어그램

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

 

회원 서비스 객체 이름 : MemberServiceImpl

여기서 Impl은 인터페이스에 대한 구현체가 하나일 때는 관례상 클래스명에 이것을 붙혀주는 것이에요.

 

 

 

    📍회원 도메인 개발

         👉 회원 Entity

• 회원 등급

 

반응형

 

• 회원 Entity

 

 

 

         👉 회원 저장소

• 회원 저장소 인터페이스

 

 

• Memory 회원 저장소 구현체

 

DB에 대해서 어떤 것을 사용할지 아직 결정 되지 않았다는 가정하에 진행하는 것이에요.

이렇다고 하더라도 개발은 진행할 수 있답니다! 그건 단순하게 Memory를 활용하여 회원 저장소를 구현하는 것이에요.

💡참고:
[HashMap]은 동시성 Issue가 발생할 수 있다. 이런경우 [CocurrentHashMap]을 사용할 수 있다.

동시성 Issue란?
먼저 이것을 이야기 전에 Thread(스레드)를 이해해야 하고, 이 스레드를 이해하기 위해 프로세스를 먼저 이해해야 한다.

프로세스란? 일반적으로 특정 작업을 수행하는 소프트웨어를 프로그램이라 한다. 이 프로그램이 실제로 실행되어, Memory나 CPU와 같은 자원을 할당 받으면 이것을 프로세스라고 부른다.

스레드란? 위의 프로세스를 구성하는 하나의 단위를 말한다. 즉, 하나의 프로세스는 여러 스레드가 작동하고 있을 수 있다.

스세드는 작업의 한 단위로 프로세스는 독자적인 Memory를 할당 받아 서로 다른 프로세스 끼리는 일반적으로 서로의 메모리 영역을 침범하지 못한다. 하지만, 프로세스 내부에 있는 여러 스레드들은 서로 같은 프로세스 내부에 존재하기 때문에 같은 자원을 공유할 수 있다. 같은 자원을 공유하는 것으로 인해 동시에 여러 일을 같은 자원을 두고 수행할 수도 있고, 이 때문에 곧 병렬성의 향상을 도모할 수 있다.

하지만, 단점도 존재한다. 여러 스레드가 동시에 하나의 자원을 공유하고 있기 때문에 이 자원을 두고 동시성 문제, 데드락과 같은 문제들이 발생할 수 있다. 이 문제를 해결해야 멀티 스레드 환경에서 문제 없는 프로그램을 제작할 수 있게 된다.

 

 

         👉 회원 서비스

• 회원 서비스 인터페이스

 

 

• 회원 서비스 구현체

 

위와 같이 프로그래밍을 하면 어떤 문제가 있을까요?

그것은 바로 다른 저장소로 변경할 때 OCP 원칙과 DIP를 지키고 있지 않다는 문제가 발생해요.

OCP와 DIP에 대한 내용을 모르신다면 여기에 관심을 주세요!

위 코드 9번째 줄을 보면 의존관계가 인터페이스 뿐만 아니라 구현체까지 모두 의존하는 것을 확인할 수 있는 것이에요.

앞에서는 MemberRepository로 인터페이스를 의존하나, 뒤에서는 new를 통해 MemoryMemberRepository를 의존하고 있는 것이에요. 이게 바로 문제인 것이에요!

 

         👉 회원 도메인 - 회원 가입 Test

 

 

위에 Test Code는 JUnit을 통한 Test인 것이에요.

 

 

 

    📍주문과 할인 도메인 설계

1. 주문과 할인 정책
   • 회원은 상품을 주문할 수 있다.
   • 회원 등급에 따라 할인 정책을 적용할 수 있다.
   • 할인 정책으로 모든 VIP는 1,000원을 할인해주는 고정 금액 할인을 적용해달라고 한다. (나중에 변경될 수 있음)
   • 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직  정했고, 오픈 직전까지 고민을 미루고 싶다.
     최악의 경우 할인을 적용하지 않을수도 있다.

 

 

 

         👉 주문 도메인 협력, 역할 책임

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

위의 그림에서 Client는 Spring MVC의 경우엔 Controller로 볼 수 있고, JAVA의 경우 Main()로 볼 수 있는 것이에요.

1. 주문 생성 : Client는 주문 서비스에 주문 생성을 요청한다.
2. 회원 조회 : 할인을 위해서는 회원 등급이 필요하므로, 주문 서비스는 회원 저장소에서 회원을 저장한다.
3. 할인 적용 : 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다.
4. 주문 결과 반환 : 주문 서비스는 할인 결과를 포함한 주문 결과를 반환한다.

 

 

         👉 주문 도메인 전체

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

 

 

역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계해야 하는 것이에요. 그래야 회원 저장소는 물론이고, 할인 정책도 유연하게 변경할 수 있답니다!

 

 

         👉 주문 도메인 클래스 다이어그램

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

 

 

 

 

         👉 주문 도메인 객체 다이어그램1

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

 

회원을 Memory에서 조회하고, 정액 할인 정책(고정 금액)을 지원해도 주문 서비스를 변경하지 않아도 되는 것이에요.

결국 역할들의 협력 관계를 그대로 재사용 할 수 있게 된 것이에요. 이것이 무슨 말이냐면 저장소를 Memory에서 DB로 변경하고, 할인 정책을 정액에서 정률로 변경해도 주문 서비스 구현체를 변경할 필요가 없다는 이야기인 것이에요.

 

 

         👉 주문 도메인 객체 다이어그램2

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

 

 

회원을 Memory가 아닌 실제 DB에서 조회하고, 정률 할인 정책(주문 그램에 따라 % 할인)으로 방식을 바꾸어도 주문 서비스를 변경하지 않아도 되는 것이에요. 다시 한번 언급하지만 협력 관계를 그대로 재사용 할 수 있는 것이에요!

 

 

 

 

    📍주문과 할인 도메인 개발

         👉 할인 정책 인터페이스

 

 

         👉 정액 할인 정책 구현체

 

 

위의 13번째 줄 if문을 분석해 보면 회원의 등급이 VIP라면 'discountFixAmount'변수를 반환해서 1000원을 할인 할 수 있게 연산할 수 있도록 해주고, 아니면 할인이 없게 '0'을 반환 하는 것이에요.

 

 

 

 

         👉 주문 Entity

package hello.core.order;

public class Order {
    private Long memberId;
    private String itemName;
    private int itemPrice;
    private int discountPrice;

    public int calculatePrice() {
        return itemPrice - discountPrice;
    }

    public Order(Long memberId, String itemName, int itemPrice, int discountPrice) {
        this.memberId = memberId;
        this.itemName = itemName;
        this.itemPrice = itemPrice;
        this.discountPrice = discountPrice;
    }

    public Long getMemberId() {
        return memberId;
    }

    public void setMemberId(Long memberId) {
        this.memberId = memberId;
    }

    public String getItemName() {
        return itemName;
    }

    public void setItemName(String itemName) {
        this.itemName = itemName;
    }

    public int getItemPrice() {
        return itemPrice;
    }

    public void setItemPrice(int itemPrice) {
        this.itemPrice = itemPrice;
    }

    public int getDiscountPrice() {
        return discountPrice;
    }

    public void setDiscountPrice(int discountPrice) {
        this.discountPrice = discountPrice;
    }

    @Override
    public String toString() {
        return "Order{" +
                "memberId=" + memberId +
                ", itemName='" + itemName + '\'' +
                ", itemPrice=" + itemPrice +
                ", discountPrice=" + discountPrice +
                '}';
    }
}

 

 

 

 

         👉 주문 서비스 구현체

 

order 서비스에 입장에서 할인에 대해서는 몰라도 되는 것이에요. '알아서 계산하고, 나한테 결과만 줘!' 라고 하는 것과 같은 것이에요.

주문 생성 요청이 오면, 회원 정보를 조회하고 (16번째 줄), 고정 금액 할인 정책을 적용(18번째 줄)한 뒤 주문 객체를 생성해서 반환하는 것이에요. 

메모리 회원 레포지토리와 고정 금액 할인 정책을 구현체로 생성하게 되는 것이지요!

 

 

 

 

    📍주문과 할인 도메인 Test

         👉 주문과 할인 정책 Test

 

 

 

정상적으로 잘 실행 되네요!

 

 

---

 

 

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