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

1. 기존 설계 문제점

 

섹션2. 주문과 할인 도메인 설계

추가한 할인 정책 적용

- 문제점 

 

위 자료를 보자.

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

 

 

이는 다형성을 활용하여, 역할(interface)과 구현(class)을 분리했지만

 

- OCP(: 변경하지 않고 확장이 가능하다)를 위반하는 것을 확인할 수 있다.

 

- 또한 인터페이스뿐만 아니라 구체 클래스에도 의존하고 있다. DIP(: 구체화가 아닌, 추상화에 의존해야한다.) 위반

 

 

 

 

 

- 해결방안 

 

인터페이스에만 의존하도록 코드를 변경해야한다.

 

즉, 클라이언트인 OrderServiceImpl에 구현 객체를 대신 생성하고 주입해주어야 한다.

 

위와 같이 '생성자 주입' 방식으로 코드 변경

 

별도의 설정 클래스 생성

 

 

AppConfig 

 

: 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고

  생성자를 통해서 연결하는 책임을 가지는 별도의 설정 클래스를 만든다. <의존관계 주입>

 

이로써, 애플리케이션이 크게 "사용 영역"과, 객체를 생성하고 구성하는 "구성 영역"으로 분리되었다.

→ 할인 / 데이터베이스 정책을 변경해도 AppConfig의 구성 영역만 변경하면 된다.

 

 

 

---

 

 

 

 

2. IoC, DI, 그리고 컨테이너

 

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

 

클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성 / 연결 / 실행하는 기존의 흐름에서

 

프로그램의 제어 흐름을 AppConfig 에 위임하고, 구현 객체는 자신의 로직을 충실히 실행하는 흐름으로 바뀌는 것

 

 

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

 

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

→ 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

 

 

3) 컨테이너

 

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 "IoC 컨테이너" 또는 "DI 컨테이너"라 한다.

 

 

 

 

---

 

 

 

 

3. 스프링으로 전환하기

 

1)

ApplicationContext 를 스프링 컨테이너라 한다.

 → ex> ApplicationContext applicationContext = new AnnotaionConfigApplicationContext(AppConfig.class)

 

 

2)

@Configuration

 - 'AppConfig의 설정으로 구성' 한다는 의미

 

 

3)

@Bean

 - 각 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다.

 - 위의 객체를 스프링 빈이라 한다.

 - @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다.

 - 이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만,

   이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 한다.

   → ex> applicationContext.getBean("orderService", OrderService.class)

 

 

 

 

출처 : 김영한님의 스프링 핵심 원리 - 기본편 (link)