목록스터디 (47)
꼬물꼬물

스프링 컨테이너 생성 // ApplicationContext == 스프링 컨테이너 // AppConfig의 환경설정 정보를 가지고 스프링이 이 안에 있는 것들을 스프링 컨테이너에 넣어 관리해준다. ApplicationContext applicationContext = new AnnotationConfigReactiveWebApplicationContext(AppConfig.class); // 즉, 어노테이션 기반으로 스프링 컨테이너를 만들어라 ApplicationContext를 스프링 컨테이너라 한다. ApplicationContext는 인터페이스다. 컨테이너가 AppConfig.class를 살펴보고 어던것을 관리(객체 생성)할 지 선택한다. @Bean을 모두 호출 스프링 컨테이너는 파라미터로 넘어온 설..

IoC, DI 그리고 컨테이너 제어의 역전 IoC(Inversion of Control): 프레임워크가 대신 호출 기존 프로그램은 클라이언트 구현 객체가 스스로 서버 구현 객체를 생성, 연결을 실행했다. 즉, 구현체가 프로그램의 제어 흐름을 조종 AppConfig의 등장으로 구현 객체는 자신의 로직을 실행하는 역할만 담당. 프로그램의 제어 흐름은 AppConfig가 담당한다. ex) OrderServiceImple은 필요한 인터페이스를 호출할 뿐 어떤 구현 객체가 실행되는지 모른다. 프로그램의 제어 흐름에 대한 권한은 AppConfig가 가지고 있으며 OrderServiceImpl도 AppConfig가 생성한다. 이렇게 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전..

새로운 구조와 할인 정책 적용 처음으로 돌아가 정액 할인 정책을 정률 할인 정책으로 변경하자. Fix -> RateDiscountPolicy AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. // 생성자를 통해 주입한다. public class AppConfig { private DiscountPolicy discountPolicy() { // return new FixDiscountPolicy(); return new RateDiscountPolicy(); } } 할인 정책을 변경해도 애플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 된다. 클라이언트 코드인 OrderServiceImpl을 포함해서 사용..

관심사의 분리 애플리케이션을 공연, 각각의 인터페이스는 배역이라고 생각하자. 실제 배역에 맞는 배우를 선택하는 것은 누구일까? 역할을 누가할지는 배우가 정하는 것이 아니다. 이전 코드는 마치 역할(인터페이스)을 하는 남배우가 이 다른 역할을 할 여배우를 직접 초빙하는 것과 같다. -> 다양한 책임을 갖게 됨. 관심사를 분리하자! 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다. 남배우는 어떤 여배우가 선택되더라도 똑같은 공연을 해야한다. 공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 지정하는 책임을 담당하는 별도의 "공연 기획자"가 나와야한다. 공연 기획자를 만들어, 배우와 공연 기획자의 책임을 확실하게 분리하자! AppConfig 등장 애플리케이션의 전체 동작 방식을 구성(co..