Spring Project

1. 프로젝트 생성

1) 비즈니스 요구사항과 설계

회원

회원 서비스 : 회원 가입/조회 가능
회원 등급 : 일반/VIP
회원 데이터 관리(미확정)

주문과 할인 정책

회원은 상품 주문 가능
회원 등급에 따라 할인 정책 적용(미확정)
모든 VIP는 1000원을 할인해주는 고정 금액 할인 적용(추후 변경 가능성)

  • 회원 데이터와 할인 정책이 미확정일 때, 개발을 무기한 연기할 수 없기 때문에 이런 경우에 인터페이스를 만들고 구현체를 언제든 갈아끼울 수 있도록 역할과 구현을 분리해주는 설계가 필요함

2) 회원 도메인 설계

회원 도메인 요구사항

회원 서비스 : 회원 가입/조회 가능
회원 등급 : 일반/VIP
회원 데이터 관리(미확정)

회원 클래스 다이어그램

회원 객체 다이어그램

3) 주문/할인 도메인 설계

주문/할인 도메인 요구사항

회원은 상품 주문 가능
회원 등급에 따라 할인 정책 적용(미확정)
모든 VIP는 1000원을 할인해주는 고정 금액 할인 적용(추후 변경 가능성)

주문 도메인 협력 관계

  1. 주문 생성 : 클라이언트는 주문 서비스에 주문 생성을 요청
  2. 회원 조회 : 주문 서비스는 회원 저장소에서 회원을 조회
  3. 할인 적용 : 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임
  4. 주문 결과 반환 : 주문 서비스는 할인 결과를 포함한 주문 결과를 반환

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

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

  • 회원을 메모리에서 조회하고 정액 할인 정책을 지원해도 주문 서비스를 변경하지 않아도 됨
    => 역할들의 협력 관계를 그대로 재사용할 수 있음 !

2. 객체 지향 원리 적용

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

서비스 오픈 직전에 할인 정책을 기존의 고정 금액 할인이 아닌 주문 금액당 할인하는 정률%할인으로 변경하게 되는 경우

  • 정률 할인으로 할인 정책을 변경하기 위해선 RateDiscountPolicy 구현체를 추가해야 하고, 추가한 할인 정책을 적용하기 위해선 클라이언트인 OrderServiceImpl 코드를 고쳐야 함 
public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository = new MemoryMemberRepository();
//    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
    ...
}

기능을 확장해서 변경하면 클라이언트 코드에 영향을 줌
=> OCP 위반

추상 뿐만 아니라 구체 클래스에도 의존을 하게 됨

  • 인터페이스(추상) DiscountPolicy 의존
  • 구현 클래스(구체) FixDiscountPolicy, RateDiscountPolicy 의존
    => DIP 위반
  • 역할과 구현을 분리했고, 다형성을 활용하고 인터페이스와 구현 객체를 분리했지만 OCP, DIP를 위반하는 문제점이 발생함

2) 문제 해결 - 관심사 분리

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private DiscountPolicy discountPolicy;
    ...
}
  • 인터페이스에만 의존하도록 코드를 변경해줌
  • 하지만 구현체가 없기 때문에 Null pointer exception이 발생함
  • 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해줘야 함

관심사 분리

애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고 연결하는 책임을 가지는 별도의 설정 클래스 생성
= 객체를 생성하고 연결하는 역할과 실행하는 역할을 명확히 구분

'AppConfig'

  • 애플리케이션에 대한 환경 설정 담당(객체의 생성과 연결)
  • 애플리케이션의 실제 동작에 필요한 구현 객체를 생성함
public class AppConfig {

    public MemberService memberService(){
        // memoryMemberRespository 객체를 생성하고,
        // 생성한 객체 인스턴스의 참조값을 memberServiceImpl을 생성하면서 생성자로 주입시킴
        return new MemberServiceImpl(new MemoryMemberRepository());
    }

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

}
  • AppConfig를 통해 누군가 MemberService나 OrderService를 조회하면 MemberServiceImpl이나 OrderServiceImpl이 반환되는데, 거기에 MemoryMemberRepository 생성자나 FixDiscountPolicy 생성자가 주입됨

MemberServiceImpl

  • MemberRepository 인터페이스(추상)에만 의존하게 됨
  • 생성자를 통해 어떤 구현 객체가 들어올지 알 수 없음
  • 오로지 외부 AppConfig에서 구현 객체 주입이 결정됨
  • 의존 관계를 마치 외부에서 주입해주는 것과 같아서
    DI(Dependency Injection) = 의존관계(의존성) 주입이라고 함
public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;

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

OrderServiceImpl

  • 인터페이스(추상)에만 의존하면 되고, 구체 클래스를 몰라도 됨
    = DIP를 지키고 있음
  • 생성자를 통해 어떤 구현 객체가 들어올지는 알 수 없음
  • 오직 외부 AppConfig에서 구현 객체 주입이 결정되기 때문에 본인 로직 실행에만 집중하면 됨
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;
    }

MemberServiceTest

public class MemberServiceTest {

    MemberService memberService;

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

OrderServiceTest

public class OrderServiceTest {

    MemberService memberService;
    OrderService orderService;

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

3) AppConfig Refactoring

현재 AppConfig 코드에 존재하는 중복을 제거하고,
역할과 구현을 명확하게 분리하기 위함

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();
    }
    
}
  • new MemoryMemberRespository() 중복이 제거됨
  • MemoryMemberRepsitory를 다른 구현체로 변경할 때 하나의 부분만 변경하면 됨
  • 변경된 AppConfig를 통해 역할과 구현 클래스를 한눈에 파악할 수 있음

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

  • AppConfig를 통해 애플리케이션이 사용 영역과 객체를 생성하고 구성하는 영역으로 구분됨
  • 따라서 할인 정책을 변경해도 구성 영역만 영향을 받고, 사용 영역은 전혀 영향을 받지 않게 됨
public class AppConfig {
    ...
    public OrderService orderService(){
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

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

}
  • AppConfig에서 할인 정책 역할을 담당하는 구현을 FixDiscountPolicy에서 RateDiscountPolicy 객체로 변경함
  • 할인 정책을 변경할 때 애플리케이션 구성 역할을 담당하는 AppConfig만 변경하면 되고, 클라이언트 코드인 OrderServiceImpl는 변경하지 않아도 됨
    = OCP를 지키고 있음

5) SOLID 적용

해당 프로젝트에서는 SRP, DIP, OCP 3가지 원칙이 적용됨

SRP

  • '한 클래스는 하나의 책임만 가져야 한다'
  • 구현 객체를 생성하고 연결하는 책임을 AppConfig가 담당
  • 클라이언트 객체는 실행하는 책임만 담당

DIP

  • '프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다'
  • 의존성 주입이 이 원칙을 따르는 방법 중 하나
  • 클라이언트 코드가 추상화 인터페이스에만 의존하도록 코드를 변경함
  • 클라이언트 코드는 인터페이스만으로 아무것도 실행할 수 없기 때문에,
    AppConfig가 객체 인스턴스를 클라이언트 코드 대신 생성하여 클라이언트 코드에 의존 관계를 주입함

OCP

  • '소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀있어야 한다'
  • 애플리케이션을 사용 영역과 구성 영역으로 구분
  • AppCofig가 의존 관계를 변경해서 클라이언트 코드에 주입하므로 클라이언트 코드는 변경하지 않아도 됨
  • 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀 있음

6) IoC(Inversion of Control) : 제어의 역전

  • OrderServiceImpl은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행되는지 알 수 없음
  • 프로그램 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있음
  • 구현 객체는 자신의 로직을 실행하는 역할만 담당함
  • 이처럼 프로그램 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라고 함

    프레임워크 : 내가 작성한 코드를 제어하고 대신 실행(JUnit)
    라이브러리 : 내가 작성한 코드가 직접 제어의 흐름을 담당

7) DI(Dependency Injection) : 의존관계 주입

  • 의존 관계는 정적인 클래스 의존 관계와 실행 시점에서 결정되는 동적인 객체(인스턴스) 의존 관계 두가지로 분리해서 생각해야 함

정적인 클래스 의존 관계

  • 클래스가 사용하는 import 코드만 보고 의존 관계 판단 가능
  • 애플리케이션을 실행하지 않아도, OrderServiceImp가 MemberRepository와 DiscountPolicy에 의존한다는 것을 알 수 있음
  • 하지만 어떤 객체가 OrderServiceImpl에 주입되는지는 알 수 없음

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

  • 애플리케이션 실행 시점에서 외부에서 생성된 실제 객체 인스턴스의 참조값이 클라이언트에게 전달되어 연결됨 (의존관계 주입)
  • 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있음
  • 또 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있음
  • AppConfig와 같이 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 IoC 컨테이너 또는 DI 컨테이너라고 함
    (최근엔 의존관계에 초점을 맞춰 DI 컨테이너라고 주로 부름)

3. Spring Container

자바 코드만으로 DI를 적용했던 것을 스프링을 사용하는 코드로 전환

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    @Bean
    public OrderService orderService(){
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }
    @Bean
    public DiscountPolicy discountPolicy(){
        return new RateDiscountPolicy();
    }
}
public class MemberApp {
    public static void main(String[] args) {
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        ...
    }
}
public class OrderApp {
    public static void main(String[] args) {
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);
        ...
    }
}
  • ApplicationContext : 스프링 컨테이너
  • 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정 정보로 사용하고, @Bean이라고 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록함
...
Creating shared instance of singleton bean 'appConfig'
Creating shared instance of singleton bean 'memberService'
Creating shared instance of singleton bean 'memberRepository'
Creating shared instance of singleton bean 'orderService'
Creating shared instance of singleton bean 'discountPolicy'
...
  • spring bean : 스프링 컨테이너에 등록된 객체
    (@Bean이 붙은 메서드 명을 스프링 빈의 이름으로 사용)
  • 스프링 컨테이너를 통해 필요한 스프링 빈 객체를 찾을 수 있음
    <= applicationContext.getBean() 메서드 사용

출처 : 스프링 핵심 원리 - 기본편

TIL35, 오늘 마주친 버그
WET_3 | SystemCheckError

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
best100-homepage