스프링 핵심 원리 - 기본편 2일차

섹션2 스프링 핵심 원리 이해1 - 예제 만들기

회원 도메인 개발, 회원 도메인 실행과 테스트, 주문과 할인 도메인 설계

실습

주문과 할인 도메인 개발

• 협력 관계를 정의할 때 역할과 구현을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계하는 것이 좋다. 덕분에 회원 저장소는 물론이고, 할인 정책도 유연하게 변경할 수 있다.

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

실습

 

섹션3 스프링 핵심 원리 이해2 - 객체 지향 원리 적용

새로운 할인 정책 개발

• @DisplayName(""): 파라미터값으로 테스트할 메서드를 문장으로 요약할 수 있다.

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

• 새로운 할인 정책인 정률 할인 정책을 적용하려면 객체 생성을 새롭게 해야 한다. 이로 인해 발생하는 문제점이 있다.
  • DIP: 주문 서비스 클라이언트는 할인 정책 인터페이스에만 의존하는 것 같지만 구현한 클래스에도 의존하고 있다.
    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
                             인터페이스                                                   구현 클래스
  • OCP: 만약 FixDiscountPolicy를 RateDiscountPolicy로 바꾸면 결국 클라이언트 코드도 바꿔야 한다. 
  • 이런 문제를 해결하려면 private final DiscountPolicy discountPolicy;로만 선언하면 되는데 이러면 NPE가 발생한다. 그래서 클라이언트 객체에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해야 한다.

관심사의 분리

• 예를 들어, 애플리케이션은 공연이고 각각의 인터페이스는 배역이라고 하자 그럼 실제 배역을 담당하는 배우는 누가 선택하는가?
• 로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할지 줄리엣 역할을 누가 할지는 배우들이 정하는 것이 아니다. 이전에 한 코드는 마치 로미오 역할을 하는 배우가 줄리엣 역할을 할 배우를 직접 초빙하는 것과 같다. 그럼 로미오 역할을 하는 배우는 공연도 하고 동시에 줄리엣 역할 배우를 공연에 직접 초빙해야하는 다양한 책임을 가지고 있다.
• 관심사를 분리하자
  • 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다.
  • 로미오 역 배우는 어떤 줄리엣 배우가 선택되더라도 똑같이 공연을 할 수 있어야 한다.
  • 공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 지정하는 책임을 담당하는 별도의 공연 기획자가 나올 시점이다.
  • 공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실히 분리해야 한다.
• AppConfig 만들기: 애플리케이션의 전체 동작 방식을 구성(config)하기 위해 구현 객체를 생성하고 연결하는 책임을 가지는 별도의 설정 클래스를 만드는 것이 좋다. AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다. 그 후 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해 주입된다