[1] 프로젝트 생성

https://start.spring.io/


[2] 비즈니스 요구사항과 설계

회원

  • 회원을 가입하고 조회할 수 있다.
  • 회원은 일반과 VIP 두 가지 등급이 있다.
  • 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)

주문과 할인 정책

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

요구사항을 보면 회원 데이터, 할인 정책 같은 부분은 '지금' 결정하기 어려운 부분이다.

그렇다고 이런 정책이 결정될 때 까지 개발을 무기한 기다릴 수 도 없다. 

이 때, '객체 지향 설계 방법'을 이용하면 된다.

인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계하면 된다.

 

참고: 프로젝트 환경설정을 편리하게 하려고 스프링 부트를 사용한 것이며, 지금은 스프링 없는 순수한 자바로만 개발을 진행하고 있다.

[3] 회원 도메인 설계

회원 도메인 협력 관계

  • 클라이언트가 회원 서비스를 호출
    • 회원 서비스에는 두가지 기능이 존재
      • 회원 가입
      • 회원 조회
  • 회원 저장소라는 interface를 별도로 구축
    • 회원 데이터에 접근하는 계층을 만드는 것
    • 아직 자체 DB를 구축할 지, 외부 시스템과 연동할 지 미정이기 때문에, 확정 된 후에 그 부분의 코드만 작성하여 갈아끼울 예정

 

회원 클래스 다이어그램

  • 정적

 

회원 객체다이어그램

  • 객체 간의 참조를 나타냄
  • 동적

  • 회원 도메인 협력 관계 ← 기업에서도 볼 수 있도록 한 다이어그램
  • 회원 클래스 다이어그램 ← 개발자가 도메인 협력 관계를 구체화 시킨 것

[4] 회원 도메인 개발

  • 이 다이어그램을 보고 실제로 개발해보자

회원 엔티티

  • 회원 등급 : hello.core>member>Grade(Enum)
    • 회원 등급인 BASIC과 VIP
package hello.core.member;

public enum Grade {
    BASIC,
    VIP
}

 

  • 회원 엔티티 : hello.core>member>Member
    • member객체는 자신의 id와 name, grade를 가지고 있음
package hello.core.member;

public class Member {

    private Long id;
    private String name;
    private Grade grade;

    public Member(Long id, String name, Grade grade) {
        this.id = id;
        this.name = name;
        this.grade = grade;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Grade getGrade() {
        return grade;
    }

    public void setGrade(Grade grade) {
        this.grade = grade;
    }

}

 

회원 저장소

  • 회원 저장소 인터페이스 : hello.core>member>MemberRepository(Interface)
package hello.core.member;

public interface MemberRepository {
    void save(Member member);

    Member findById(Long memberId);
}

 

  • 메모리 회원 저장소 구현체 : hello.core>member>MemoryMemberRepository
    • MemberRepository를 implements → 상속받음
    • save() : store이라는 Map에서 member의 Id를 저장시킴
    • findById() : store이라는 Map에서 memberId를 반환
package hello.core.member;

import java.util.HashMap;
import java.util.Map;

public class MemoryMemberRepository implements MemberRepository{
    private static Map<Long, Member> store = new HashMap<>();

    @Override
    public void save(Member member){
        store.put(member.getId(), member);
    }

    @Override
    public Member findById(Long memberId){
        return store.get(memberId);
    }
}

 

회원 서비스

  • 회원 서비스 인터페이스 : hello.core>member>MemberService(interface)
    • 회원 서비스 인터페이스
    • join()
      • 회원 가입 기능
    • findMember()
      • 회원 조회 기능
package hello.core.member;

public interface MemberService { //회원 가입 및 조회 기능
    void join(Member member);

    Member findMember(Long memberId);
}

 

  • 회원 서비스 구현체 : hello.core>member>MemberServiceImpl
    • 구현체 하나만 있을 때는 관례상 interface명 뒤에 Impl이라 많이 사용
package hello.core.member;

public class MemberServiceImpl implements MemberService{

    //가입하고 회원을 찾으려면 MemberRepository가 필요
    private final MemberRepository memberRepository = new MemoryMemberRepository();

    @Override
    public void join(Member member) {
        //join에서 save 호출하면 MemberRepository가 아닌 
				// MemoryMemberRepository의 save가 호출된다 (오버라이드)
        memberRepository.save(member);
    }

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

[5] 회원 도메인 실행과 테스트

  • 클래스가 개발이 다 되었으니 잘 돌아가는지 확인해보고자 테스트를 한다
  • 클라이언트는 회원서비스(즉, MemberServiceImpl)을 사용하며, 회원서비스는 메모리회원저장소(즉, MemoryMemberRepository)를 사용하는지에 대한 확인을 할 것이다
  • 따라서 인스턴스가 위와 같은 관계로 참조되는지 확인하기 위해 위 다이어그램처럼 구현하여 test를 할 것이다

순수 Java 코드로만 test하기

  • 회원 도메인 - 회원 가입 main : hello.core>MemberApp 
package hello.core;

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

public class MemberApp {
    public static void main(String[] args) { //psvm만 쳐도 ㄱㅊ
        MemberService memberService = new MemberServiceImpl();

        // new 뒤에만 쓰고 전체 블록 잡은 후 Ctrl Alt V
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);

        System.out.println("new member = " + member.getName());
        //soutv 해주면 위 sout문과 동일한 형식으로 자동완성
        System.out.println("find Member = "+findMember.getName());
    }
}

실행결과

  • 하지만 이렇게 애플리케이션 로직으로 test하는 것은 좋지 않다
  • JUnit test를 사용하자

자동화된 JUnit test로 test하기

  • 회원 도메인 - 회원 가입 테스트 : test>java>hello.core>member>MemberServiceTest
package hello.core.member;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

public class MemberServiceTest {

    MemberService memberService = new MemberServiceImpl();

    @Test
    void join(){
        //given
        Member member = new Member(1L, "memberA", Grade.VIP);

        //when
        memberService.join(member);
        Member findMember = memberService.findMember(1L);

        //then
        Assertions.assertThat(member).isEqualTo(findMember);
    }
}
  • given에서의 member과 when에서의 findMember이 동일하므로 test통과가 뜸

  • 만약 다르다면 아래와 같이 오류가 뜰것
    • when에서의 findMember을 findMember(2L)로 변경 후 test실행 시


[6] 주문과 할인 도메인 설계

  1. 주문 생성: 클라이언트는 주문 서비스에 주문 생성을 요청한다.
  2. 회원 조회: 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회한다.
  3. 할인 적용: 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다.
  4. 주문 결과 반환: 주문 서비스는 할인 결과를 포함한 주문 결과를 반환한다.
참고: 실제로는 주문 데이터를 DB에 저장하겠지만, 예제가 너무 복잡해 질 수 있어서 생략하고, 단순히 주문 결과를 반환한다.

주문 도메인 전체

  • 정액 할인 정책 : 구매 가격과 무관하게 항상 동일 금액 할인
  • 정률 할인 정책 : 구매 가격에 따른 할인 금액
    • 10000원 →10%할인→ 1000원 할인
    • 20000원 →10%할인→ 2000원 할인
  • 역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계했다. 덕분에 회원 저장소는 물론이고, 할인 정책도 유연하게 변경할 수 있다.

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

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

  • 회원을 메모리에서 조회하고, 정액 할인 정책(고정 금액)을 지원해도 주문 서비스를 변경하지 않아도 된다.
  • 역할들의 협력 관계를 그대로 재사용 할 수 있다.

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

  • 회원을 메모리가 아닌 실제 DB에서 조회하고, 정률 할인 정책(주문 금액에 따라 % 할인)을 지원해도 주문 서비스를 변경하지 않아도 된다.
  • 협력 관계를 그대로 재사용 할 수 있다.

[7] 주문과 할인 도메인 개발

할인 정책 인터페이스

  • hello.core>discount>DiscountPolicy(interface)
package hello.core.discount;

import hello.core.member.Member;

public interface DiscountPolicy {

    /**
     *
     * @return 할인 대상 금액
     */
    int discount(Member member, int price);

}

정액 할인 정책 구현체

  • hello.core>discount>FixDiscountPolicy
package hello.core.discount;

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

public class FixDiscountPolicy implements DiscountPolicy{

    //구매가격 무관하게 무조건 1000원 할인
    private int discountFixAmount = 1000;
    @Override
    public int discount(Member member, int price) {
        if(member.getGrade() == Grade.VIP){
            return discountFixAmount;
        }
        else{
            return 0;
        }
    }
}
  • 구매가격 무관하게 무조건 1000원 할인

주문 엔티티

  • hello.core>order>Order
package hello.core.order;

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

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

    public int calculatePrice(){ // 최종 계산된 금액(할인 금액을 빼준 금액)
        return itemPrice - 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 +
                '}';
    }
}
  • calculatePrice() : 최종 계산된 금액(할인 금액을 빼준 금액)
  • toString() : sout 하면 이 메소드의 반환값이 출력됨

주문 서비스 인터페이스

  • hello.core>order>OrderService
package hello.core.order;

public interface OrderService {
    // 주문 생성 시, 회원 id, 상품명, 상품가격을 파라미터로 넘겨주어야 함
    // (1. 주문 생성) 부분
    Order createOrder(Long memberId, String itemName, int itemPrice);
}
  • (1) 주문 생성 부분 구현

주문 서비스 구현체

  • hello.core>order>OrderServiceImpl
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); //회원 찾기

        /**
         * orderServie입장에서는 할인에 대해서는 잘 모르겠고,
         * discountPolicy에게 알아서 해달라고 맡기고 반환값만 달라고 하는 것
         *
         * 이제 할인에 대한 수정이 필요하면 order 수정 없이 discountPolicy만 수정하면 된다
         */
        int discountPrice = discountPolicy.discount(member, itemPrice);

        // 4. 주문 결과 반환
        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}
  • (4) 주문 결과 반환 부분 구현

  • 주문 생성 요청이 오면, 회원 정보를 조회하고, 할인 정책을 적용한 다음 주문 객체를 생성해서 반환한다.
  • 메모리 회원 리포지토리와, 고정 금액 할인 정책을 구현체로 생성한다.

[8] 주문과 할인 도메인 실행과 테스트

순수 Java코드로만 test하기

  • 주문과 할인 정책 실행 : hello.core>OrderApp
package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.order.Order;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class OrderApp {
    public static void main(String[] args) {
        MemberService memberService = new MemberServiceImpl();
        OrderService orderService = new OrderServiceImpl();

        //id가 1, 이름이 memberA, 등급이 VIP인 회원 한 명 만들어줌
        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);

        //memberService를 통해 위 member객체를 넣어줌
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);

        System.out.println("order = " + order);
        System.out.println("order = " + order.calculatePrice());
    }
}

  • sout을 통해 Order.java의 toString()이 출력된다
  • 할인 금액이 잘 출력되는 것을 확인할 수 있다.
  • 애플리케이션 로직으로 이렇게 테스트 하는 것은 좋은 방법이 아니다. JUnit 테스트를 사용하자.

자동화된 junit test로 test하기

  • 문과 할인 정책 테스트 : test>java>hello.core>order>OrderServiceTest
package hello.core.order;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

public class OrderServiceTest {
    MemberService memberService = new MemberServiceImpl();
    OrderService orderService = new OrderServiceImpl();

    @Test
    void createOrder(){
        //id가 1, 이름이 memberA, 등급이 VIP인 회원 한 명 만들어줌
        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);

        //memberService를 통해 위 member객체를 넣어줌
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);

        // VIP의 경우 1000원 할인해주기로 했으므로 동일함 -> test 통과
        Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
    }
}

 

  • hello.core에 있는 test 전부를 한번에 test해기

 

스프링 프레임워크

  • 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타
  • 웹 기술 : 스프링 MVC, 스프링 WebFlux
  • 데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
  • 기술 통합 : 캐시, 이메일 원격접근, 스케줄링
  • 테스트 : 스프링 기반 테스트 지원
  • 언어 : 코틀린, 그루비

최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용한다

 

스프링 부트

  • 스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용
  • 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
  • Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
  • 손쉬운 빌드 구성을 위한 starter 종속성 제공
  • 스프링과 3rd party(외부) 라이브러리 자동 구성
  • 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
  • 관례에 의한 간결한 설정

 

스프링 단어

  • 스프링이라는 단어는 문맥에 따라 다르게 사용된다
    • 스프링 DI 컨테이너 기술
    • 스프링 프레임워크
    • 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계

 

스프링의 핵심

  • 스프링은 자바 언어 기반의 프레임워크
  • 자바 언어의 가장 큰 특징 - 객체 지향 언어
  • 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
  • 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

 


 

[2] 좋은 객체 지향 프로그래밍이란?

객체 지향 프로그래밍

  • 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다.
    • 각각의 객체는 메시지 를 주고받고, 데이터를 처리할 수 있다. (협력)
  • 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프 트웨어 개발에 많이 사용된다.
    • 유연하고, 변경이 용이?
      • 레고 블럭 조립하듯이
      • 컴퓨터 부품 갈아 끼우듯이
      • 컴포넌트를 쉽고 유연하게 변경하면서 개발
  • 특징
    • 추상화
    • 캡슐화
    • 상속
    • 다형성

 

다형성 Polymorphism

  • 자동차 구현이 바뀌어도 운전자는 똑같이 운전할 수 있다
    • 자동차 interface에 따라 각기 다른 자동차들이 구현된 것이기 때문이다
  • 로미오와 줄리엣의 역할은 interface
  • 각 배우들은 이에 대한 구현
  • 다형성의 실세계 비유 예시
    • 운전자-자동차
    • 공연 무대
    • 키보드, 마우스, 세상의 표준 인터페이스들
    • 정렬 알고리즘
    • 할인 정책 로직

 

역할과 구현의 분리

  • 역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해진다
  • 장점
    • 클라이언트는 대상의 역할(인터페이스)만 알면 된다
    • 클라이언트는 구현 대상의 내부 구조를 몰라도 된다
    • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다
    • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다
  • in JAVA
    • 역할 = 인터페이스
    • 구현 = 인터페이스를 구현한 클래스, 구현 객체
    • 객체를 설계할 때 역할과 구현을 명확히 분리
    • 객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기

 

객체의 협력이라는 관계부터 생각

  • 혼자 있는 객체는 없다
  • 클라이언트 : 요청, 서버 : 응답
  • 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다

 

다형성 in Java

  • 오버라이딩 = 부모클래스의 메소드를 상속받아 재정의
  • 오버라이딩 된 메서드가 실행
  • 다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있다
  • 물론 클래스 상속 관계도 다형성, 오버라이딩 적용가능
  • MemberRepository를 선언해두고, 이에 MemoryMemberRepository 혹은 JdbcMemberRepository를 넣는다 (아래 코드와 같이) → 다형성이므로 가능

 

  • MemberRepository(부모)와 관계없는 class는 할당해줄 수 없다

 

  • MemoryMemberRepository를 할당해주고 save()를 호출하면 MemoryMemberRepository의 save()가 호출될 것
  • JdbcMemberRepository를 할당해주고 save()를 호출하면 JdbcMemberRepository의 save()가 호출될 것

 

다형성의 본질

  • 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다
  • 다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야함
  • 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다

 

역할과 구현 분리의 한계

  • 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에게 큰 변경이 발생한다
    • 자동차를 비행기로 변경해야 한다면?
    • 대본 자체가 변경된다면?
  • 따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다

 

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

클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리

  • SRP: 단일 책임 원칙(single responsibility principle)
  • OCP: 개방-폐쇄 원칙 (Open/closed principle)
  • LSP: 리스코프 치환 원칙 (Liskov substitution principle)
  • ISP: 인터페이스 분리 원칙 (Interface segregation principle)
  • DIP: 의존관계 역전 원칙 (Dependency inversion principle)

 

SRP 단일 책임 원칙

  • 한 클래스는 하나의 책임만 가져야 한다.
  • 하나의 책임이라는 것은 모호하다
    • 클 수 있고, 작을 수 있다
    • 문맥과 상황에 따라 다르다
  • 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
  • 예) UI 변경, 객체의 생성과 사용을 분리

 

OCP 개방-폐쇄 원칙

  • 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
  • 이런 거짓말 같은 말이? 확장을 하려면, 당연히 기존 코드를 변경?
  • 다형성을 활용해보자
  • 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
  • 지금까지 배운 역할과 구현의 분리를 생각해보자
  • 문제점
    • MemberService 클라이언트가 구현 클래스를 직접 선택
      • MemberRepository m = new MemoryMemberRepository(); //기존 코드
      • MemberRepository m = new JdbcMemberRepository(); //변경 코드
    • 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
    • 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없다.
    • 이 문제를 어떻게 해결해야 하나?
    • 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다

 

LSP 리스코프 치환 원칙

  • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다
  • 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
  • 단순히 컴파일에 성공하는 것을 넘어서는 이야기
  • 예) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반, 느리더라도 앞으로 가야함

 

ISP 인터페이스 분리 원칙

  • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
  • 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
  • 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
  • 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
  • 인터페이스가 명확해지고, 대체 가능성이 높아진다

 

DIP 의존관계 역전 원칙

  • 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
  • 쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
  • 앞에서 이야기한 역할(Role)에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다! 구현체에 의존하게 되면 변경이 아주 어려워진다
  • 그런데 OCP에서 설명한 MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다.
  • MemberService 클라이언트가 구현 클래스를 직접 선택
    • MemberRepository m = new MemoryMemberRepository();
  • DIP 위반

+ Recent posts