[JAVA 객체 지향 설계의 원칙] OCP, DIP 예제로 완전 정복 ( + 관심사 분리)

 

스프링 핵심 원리 - 기본편에서 섹션 2, 3 의 내용을 바탕으로 객체 지향 설계의 원칙 중 OCP(Open-Close Principle), DIP(Dependency Inversion Principle)에 대해 자세히 알아보려고 한다. 

 

---

 

좋은 객체 지향 설계의 원칙 5가지는 아래 포스팅에 자세히 설명되어 있으니 참고 바람.

 

https://wonisdaily.tistory.com/98

[Spring 개념] 객체 지향 설계와 스프링

 

 

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

 

DIP와 OCP 원칙을 간단한 프로젝트인 하나의 예제를 통해 이해했는데, 비즈니스 요구사항과 설계를 통해 전체 흐름에 대해 알아보자.

 

📌 회원

- 회원은 가입하고 조회할 수 있다.

- 회원은 일반과 VIP 두 가지 등급이 있다.

- 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. ( 미확정)

 

📌 주문과 할인 정책

 

- 회원은 상품을 주문할 수 있다.

- 회원 등급에 따라 할인 정책을 적용할 수 있다.

- 할인 정책은 모든 VIP는 1000원을 할인해주고 고정 금액 할인을 적용한다. ( 할인 정책은 변경될 수 있는데 고정 정책과 정률 정책이 있다고 가정한다.)

 

다음과 같은 비즈니스 요구사항이 있을 때 회원 데이터나 할인 정책 같은 부분은 당장 결정하기 어려운 부분이다. 그렇다고 이런 정책이 결정될 때까지 개발을 무기한 기다릴 수 없기에 객체 지향 설계 방법을 이용해서 인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계해본다.

 

 

 

 

📑 주문 도메인 전체

 

 

프로젝트 전체 코드는 깃허브에 업로드해놨다. 이 포스팅에서는 DIP와 OCP 이해가 주된 목적이기에 관련된 코드만 리뷰하겠다. 

 

https://github.com/ssowoni/Spring-Core-Basic

GitHub - ssowoni/Spring-Core-Basic

 

 

 

 

 

 

📑 DIP와 OCP를 지키지 못했을 때

 

순수한 자바코드만을 이용해서 코딩했을 때, DIP를 지키지 못한 코드를 예시로 들어본다. 

 

package hello.core.order;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
import hello.core.member.MemoryMemberRepository;

public class OrderServiceImpl implements OrderService {

private final MemberRepository memberRepository = new MemoryMemberRepository();
private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

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

 

 

위의 코드에서 아래 2문장은 DIP를 위반한다. DIP란 구체적인 것이 추상적인 것에 의존해야 한다는 원칙이다. 언뜻 보면 OrderServiceImpl이라는 클래스는 MemberRepository라는 인터페이스에 의존하고 있으므로 DIP를 잘 지킨 것 같지만 이 클래스는 MemoryMemberRepository, FixDiscountPolicy라는 구현 클래스에도 의존하고 있다. 또한) 만약 고정 할인 정책인 (FixDiscountPolicy)가 아닌 정량 할인 정책을 (Rate~~) 적용하고 싶다면 new FixDiscountPolicy(); 대신 new RateDiscountPolicy()로 변경하면 되는 거 아닌가 싶지만! 변경하는 순간 OCP (확장에는 열려있고 변경에는 닫혀있다)는 원칙을 위반하게 된다. 

 

private final MemberRepository memberRepository = new MemoryMemberRepository();
private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

 

 

 

📑 관심사 분리

 

따라서 관심사 분리를 해야되는데, 관심사 분리란 자신의 역할에만 집중하는 것을 의미한다. OrderServiceImpl 주문 서비스 클래스는 주문 클래스에만 집중!! 할인 정책을 선택해야 된다는 부담을 주지 않는다. 이렇게 하기 위해선 별도의 기획자를 만들어야 한다. 여기선 AppConfig라는 클래스를 만들어 관심사를 분리하려 한다. 

 

 

public class OrderServiceImpl implements OrderService{

    //private static MemberRepository memberRepository = new MemoryMemberRepository();
    // ↓ 아래 코드는 인터페이스(추상화)뿐만 아니라 구현체에도 의존하고 있는 코드, DIP 위반
    //private static DiscountPolicy discountPolicy = new FixDiscountPolicy();
    //↓ 다형성으로 다른 구현체를 변경하는 순간 OCP 위반
    //private static DiscountPolicy discountPolicy = new RateDiscountPolicy();
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy; //인터페이스에만 의존함. BUT) NullPointException 발생

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
   }

 

 

관심사 분리는 생성자를 통해 주입(연결)해주면 해결할 수 있다. 즉) 클래스 객체 선언만 하고 값 할당은 서비스 클래스 내에서 하는 것이 아닌, 생성자를 통해 다른 클래스에서 주입 받아 결정하는 것이다. 따라서 서비스 클래스에선 어떤 객체, 어떤 구현을 하는지 알 수 없게 된다. 

 

 

package hello.core;

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

public class AppConfig {

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

    public MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

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

    public DiscountPolicy discountPolicy(){
        //return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

 

 

AppConfig라는 클래스를 통해 역할에 따른 구현이 보이도록 한다면, 역할과 구현 클래스가 한 눈에 들어오게 된다. 

 

 

 

 

 

📑 전체 흐름 정리 (SRP, DIP, OCP 적용)

 

📌 SRP 단일 책임 원칙

 

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

클라이언트 객체는 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있다. SRP 단일 책임 원칙을 따르며 관심사를 분리한다. 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당하기 때문에 클라이언트 객체는 실행하는 책임만 담당하게 된다.

 

📌 DIP 의존관계 역전 원칙

 

: 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.

새로운 할인 정책을 개발하고, 적용하려고 하니 클라이언트 코드도 함께 변경해야했다. 왜냐하면 기존 클라이언트 코드(OrderServiceImpl)는 DIP를 지키며 추상화 인터페이스(DiscountPolicy) 에 의존하는 것 같지만, 구체화 클래스(FixDiscountPolicy) 에도 함께 의존했다. 이를 해결하기 위해 클라이언트 코드가 추상화 인터페이스만 의존하도록 코드를 변경했다. 하지만 클라이언트 코드는 인터페이스만으론 아무것도 실행할 수 없다. NullPointException이 발생하게 된다. 따라서 AppConfig가 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존 관계를 주입했다. 

 

 

📌 OCP 개방 폐쇄의 원칙

 

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

다형성을 사용하고 클라이언트가 DIP를 지켰다. AppConfig가 의존관계를 변경해서 클라이언트 코드에 주입하므로 클라이언트 코드에서는 변경이 따로 없다. 따라서 소프트웨어 요소를 새롭게 확장해도 사용 영역 변경은 닫혀있다.

 

 

 

 

📑 의존관계 주입 DI

 

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

 

🔑 정적인 클래스 의존관계란 ? 

 

 

: 클래스가 사용하는 import 코드만 보고 의존 관계를 쉽게 파악할 수 있다. 즉) 애플리케이션을 실행하지 않아도 분석할 수 있다. 예를 들어 OrderServiceImpl은 DiscountPolicy나 MemberRepository에 의존한다고 할 수 있다. 하지만 클래스 의존관계 만으론 실제 어떤 객체가 주입될 지 알 수 없다. 

 

 

 

 

🔑 동적 객체 인스턴스 의존 관계란?

 

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