[Spring] 3.스프링 핵심 원리 이해2 - 객체 지향 원리 적용

[Spring] 3.스프링 핵심 원리 이해2 - 객체 지향 원리 적용

 

1. 새로운 할인 정책 개발

- 요구사항 변경 (1000원 할인에서 10% 할인으로)

- [애자일] -> 계획에 따르다보단 변화에 대응하기!

- fix discount policy 말고 rate discount policy 개발해주면됨  

public class RateDiscountPolicy implements DiscountPolicy {

  private int discountPercent = 10;
  @Override
  public int discount(Member member, int price) {
    if(member.getGrade() == Grade.VIP){
      return price * discountPercent / 100;
    } else {
      return 0;
    }
  }
}

-  메서드 명에 cmd + shift + t 하면 'create new test' 나옴

   Junit 5 / 이름은 원래 명에 test 붙여주기(디폴트) -> 확인 누르기

 

테스트

class RateDiscountPolicyTest {
  RateDiscountPolicy discountPolicy = new RateDiscountPolicy();
  @Test
  @DisplayName("VIP는 10% 할인이 적용되어야 한다.")
  void vip_o() {
    //given
    Member member = new Member(1L, "memberVIP", Grade.VIP);
    //when
    int discount = discountPolicy.discount(member, 10000);
    //then
    assertThat(discount).isEqualTo(1000);
  }
  @Test
  @DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다.")
  void vip_x() {
    //given
    Member member = new Member(2L, "memberBASIC", Grade.BASIC);
    //when
    int discount = discountPolicy.discount(member, 10000);
    //then
    assertThat(discount).isEqualTo(0);
  }
}

* assertions -> option enter -> add on-demand static import for 'org.assertj.core.api.Assertions'

(static import)

---

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

할인 정책을 애플리케이션에 적용해보자

- 할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야한다.

 

* 문제점

- 역할과 구현 분리 했다 / 다형성 활용, 인터페이스와 구현객체 분리

- OCP DIP (객체 지향 설계 원칙 SOLID 원칙 준수했나?)
   -> NO!

        OCP : 변경하지 않고 확장할 수 있다고 했는데? -> 멤벗 서비스 코드 수정해야함

        DIP   : 주문 서비스 클라이언트(OrderServiceImpl)는 DiscountPolicy 인터페이스에 의존하는 것 같지만

                   추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고있다. 

                   추상(인터페이스) 의존 - DiscountPolicy

                   구현(클래스) 의존        - FixDiscountPolicy / RateDiscountPolicy

 

* 문제 해결

클라이언트 (OrderServiceImpl) 이 인터페이스(Discount Policy) 에만 의존하도록 변경하면 됨

public class OrderServiceImpl implements OrderService {
      //private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
      private DiscountPolicy discountPolicy;
}

ㄴ 구현체가 없기 때문에 NullPointerException 발생 

 

해결방안

이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy 의 구현 객체를 대신 생성하고 주입해주어야 한다.

---

3. 관심사의 분리

AppConfig

ㄴhello.cored

public class AppConfig {
  public MemberService memberService() {
    return new MemberServiceImpl(new MemoryMemberRepository());
  }
  public OrderService orderService() {
    return new OrderServiceImpl(
            new MemoryMemberRepository(),
            new FixDiscountPolicy());
  }
}

- 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스

- 생성자를 통해서 구현체가 들어감

- 클라이언트(멤버서비스) 생성될 때 구현체가 주입됨

 

 멤버 서비스

public class MemberServiceImpl implements MemberService {
  private final MemberRepository memberRepository;
  public MemberServiceImpl(MemberRepository memberRepository) {
    this.memberRepository = memberRepository;
}

-> 설계 변경으로 MemberServiceImpl은 MemoryMemberRepository를 의존하지 않는다.

-> 단지 MemberRepository 인터페이스에만 의존한다.

-> MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입) 알 수 없다.

-> MemberServiceImpl의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정된다.

-> MemberServiceImpl은 이제부터 '의존 관계에 대한 고민은 외부'에 맡기고 '실행'에만 집중하면 된다.

 

[클래스 다이어그램]

[그림-회원 객체 인스턴스 다이어그램]

 -> DI (dependency injection) 의존관계 주입

 

주문 서비스

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

-> 결국 멤버 서비스가 구현(클래스)가 아닌 역할(인터페이스)에 의존하도록 만드는 것

 

AppConfig 실행

- MemberApp

public class MemberApp {
  public static void main(String[] args) {
    AppConfig appConfig = new AppConfig();
    MemberService memberService = appConfig.memberService();

- OrderApp

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

 

Test 역시 수정해줘야함

public class MemberServiceTest {

  MemberService memberService;

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

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

  }

class OrderServiceTest {
  MemberService memberService;
  OrderService orderService;

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

  @Test
  void createOrder() {
    long memberId = 1L;
    Member member = new Member(memberId, "memberA", Grade.VIP);
    memberService.join(member);
    Order order = orderService.createOrder(memberId, "itemA", 10000);
    Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
  }
}

 

- beforeEach로 테스트 시작하기 전마다 생성

---

4. AppConfig 리팩터링

현재 AppConfig를 보면 '중복'이 있고 역할에 따른 구현이 잘 안보인다.

 

[기대하는 그림]

[AppConfig 리팩터링]

public class AppConfig {
  public MemberService memberService() {
    return new MemberServiceImpl(memberRepository());
  }
  public OrderService orderService() {
    return new OrderServiceImpl(
            memberRepository(),
            discountPolicy());
  }
  public MemberRepository memberRepository() {
    return new MemoryMemberRepository();
  }
  public DiscountPolicy discountPolicy() {
    return new FixDiscountPolicy();
  }
}

- new MemoryMemberRepository() 이 부분이 중복 제거되었다. 이제 MemoryMemberRepository 를 다른 구현체로 변경할 때 한 부분만 변경하면 된다.

- AppConfig 를 보면 역할과 구현 클래스가 한눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다.

---

5. 새로운 구조와 할인 정책 적용

FixDiscountPolicy -> RateDiscountPolicy

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

- 이 부분만 바꿔주면 된다!

-> OCP, DIP 모두 지켜짐

---

6. 좋은 객체 지향 설계의 5가지 원칙의 적용

여기서 SOLID 중 3가지 SRP / DIP / OCP 적용

 

1) SRP (단일 책임 원칙)

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

- SRP 단일 책임 원칙을 따르면서 관심사를 분리함

- 구현 객체를 생성하고 연결하는 책임은 AppConfig 가 담당

- 클라이언트 객체는 실행하는 책임만 담당

 

2) DIP 의존관계 역전 원칙

"프로그래머는 [추상화]에 의존해야지 [구체화]에 의존하면 안된다"

- 의존성 주입 (AppConfig에서 생성해서 넣어줌) -> 유연성

- 클라이언트코드가 추상화 인터페이스에 의존하도록 설정

- but 클라이언트 코드는 인터페이스만으로는 아무것도 실행할 수 없다.

- AppConfig가 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입하면서 DIP 문제 해결

 

3) OCP

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

- 다형성 사용하고 클라이언트가 DIP를 지킴

- 애플리케이션을 사용 영역과 구성 영역으로 나눔

- AppConfig가 의존 관계를 FixDiscountPolicy -> RateDiscountPolicy로 변경해서 클라이언트 코드에 주입하므로 클라이언트 코드 자체를 변경시키지 않아도 됨

- 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀 있다.

---

7. Ioc, DI, 그리고 컨테이너

1) 제어의 역전 IoC(Inversion of Control)

- 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고 연결하고 실행함

  (한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종)

- 반면 AppConfig가 등장한 이후 구현 객체는 자신의 로직을 실행하는 역할만 담당한다.

  (AppConfig가 프로그램의 제어 흐름을 가져감)

  ex) OrderServiceImpl은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모름

- 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고있다. 

  OrderServiceImpl은 자신의 로직을 실행할 뿐이다.

 

2) 프레임 워크 VS 라이브러리

- 프레임워크 : 내가 작성한 코드를 제어하고 대신 실행 (JUnit)

- 라이브러리 : 내가 작성한 코드가 직접 제어의 흐름을 담당 (라이브러리 직접 호출)

 

3) 의존관계 주입 DI(Dependency Injection)

- OrderServiceImpl은 DiscountPolicy 인터페이스에 의존 (실제 어떤 객체가 사용될지 모름)

- [정적인 클래스 의존관계] 와 [동적인 객체(인스턴스) 의존관계 - 실행시점에 결정] 을 분리해서 생각해야함

 

[정적인 클래스 의존관계]

- 애플리케이션을 실행하지 않고도 의존관계 분석 가능

- 하지만 클래스 의존관계만으로는 실제 어떤 객체가 OrderServiceImpl에 주입될지 알 수 없다

클래스 다이어그램

 

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

- 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스 의 참조가 연결된 의존 관계

객체 다이어그램

  - 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것을 의존관계 주입이라고 한다.

- 객체 인스턴스를 생성하고 그 참조값을 전달해서 연결

- 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고 클라이언트가 호출하는 대상의 타입 인스턴스를 변경 가능

- 의존관계 주입으르 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계 쉽게 변경 가능

 

Ioc 컨테이너, DI 컨테이너

- AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 IoC 컨테이너 / DI 컨테이너라고 함

- 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라고 함

- or 어셈블러 / 오브젝트 팩토리 라고도 불림

---

8. 스프링으로 전환하기

AppConfig

1) @Configuration

2) @Bean

@Configuration
public class AppConfig {
  @Bean
  public MemberService memberService() {
    return new MemberServiceImpl(memberRepository());
  }

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

  @Bean
  public MemberRepository memberRepository() {
    return new MemoryMemberRepository();
  }

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

 

MemberApp

1) ApplicationContext / AnnotationConfigApplicationContext

ㄴ 스프링 컨테이너(@Bean 관리), AppConfig 환경 설정 정보 가지고 @Bean 객체 생성한걸 스프링 컨테이너에 다 넣어서 관리해줌

ㄴ 기존에는 AppConfig에서 직접 찾아왔다면 이제 getBean("memberService" - 이름, MemberService.class - 타입);로 가져옴

public class MemberApp {
  public static void main(String[] args) {
//    AppConfig appConfig = new AppConfig();
//    MemberService memberService = appConfig.memberService();

    ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
    MemberService memberService = applicationContext.getBean("memberService", MemberService.class);

    Member member = new Member(1L, "memberA", Grade.VIP);
    memberService.join(member);

    Member findMember = memberService.findMember(1L);
    System.out.println("findMember = " + findMember.getName());
    System.out.println("member = " + member.getName());
  }
}

 

OrderApp

public class OrderApp {
  public static void main(String[] args) {
//    AppConfig appConfig = new AppConfig();
//    MemberService memberService = appConfig.memberService();
//    OrderService orderService = appConfig.orderService();

    ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
    MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
    OrderService orderService = applicationContext.getBean("orderService", OrderService.class);


    long memberId = 1L;

    Member member = new Member(memberId, "memberA", Grade.VIP);
    memberService.join(member);

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

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

 

[스프링 컨테이너]

- ApplicationContext를 스프링 컨테이너라고 함

- 기존에는 개발자가 AppConfig를 사용해서 직접 객체를 생성하고 DI를 했지만, 이젠 스프링 컨테이너를 통해서 사용

- 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정(구성) 정보로 사용 / 여기서 @Bean이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록 / 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 함

- 스프링 빈은 @Bean이 붙은 메서드의 명을 스프링 빈의 이름으로 사용 ('memberService') 

- 이전에는 필요한 객체를 AppConfig를 사용해서 직접 조회했지만, 이제부터 스프링 컨테이너를 통해 필요한 스프링 빈(객체)를 찾아야함 / 스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있음

- 기존에는 개발자가 직접 자바 코드로 모든 것을 다했다면 이제부터 스프링 컨테이너에 객체를 스프링 빈으로 등록하고 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경됨