Dev

스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법 - ac.getBean(빈이름, 타입) - ac.getBean(타입) 조회 대상 스프링 빈이 없으면 예외 발생 - NoSuchBeanDefinitionException: No bean named 'xxxxx' available 예제 코드 (ApplicationContextBasicFindTest.java) package hello.core.beanfind; import hello.core.AppConfig; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import org.assertj.core.api.Assertions; import or..

스프링 컨테이너에 실제 스프링 빈들이 잘 등록 되었는지 확인해보자 ApplicationContextInfoTest.java package hello.core.beanfind; import ch.qos.logback.core.net.SyslogOutputStream; import hello.core.AppConfig; import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test; import org.springframework.beans.factory.config.BeanDefinition; import org.springframework.context.annotation.AnnotationConfigApplicationContex..

스프링 컨테이너가 생성되는 과정을 알아보자. //스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext 를 스프링 컨테이너라 한다. ApplicationContext 는 인터페이스이다. 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. 직전에 AppConfig 를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것이다. 자바 설정 클래스를 기반으로 스프링 컨테이너( ApplicationContext )를 만들어보자. - new AnnotationCon..

스프링으로 전환하기 - 지금까지 순수한 자바 코드만으로 DI를 적용했다. 이제 스프링을 사용해보자. - 지금은 코드만 작성하고 설명은 마지막에 하겠다. AppConfig 스프링 기반으로 변경 - AppConfig에 설정을 구성한다는 뜻의 @Configuration 을 붙여준다. - 각 메서드에 @Bean 을 붙여준다. 이렇게 하면 스프링 컨테이너에 스프링 빈으로 등록한다. package hello.core; import hello.core.discount.DiscountPolicy; import hello.core.discount.FixDiscountPolicy; import hello.core.discount.RateDiscountPolicy; import hello.core.member.MemberR..

제어의 역전 IoC(Inversion of Control) - 프레임워크가 내 코드를 대신 호출, 제어권이 말 그대로 뒤바뀐다 해서 제어의 역전 - 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. - 한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다. - 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. - 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. - 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다. - 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지..

좋은 객체 지향 설계의 5가지 원칙의 적용 여기서 3가지 SRP, DIP, OCP 적용 SRP 단일 책임 원칙 - 한 클래스는 하나의 책임만 가져야 한다. - 클라이언트 객체는 직접 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있음 - SRP 단일 책임 원칙을 따르면서 관심사를 분리함 - 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당 - 클라이언트 객체는 실행하는 책임만 담당하도록 설계 변경 DIP 의존관계 역전 원칙 - 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 의존성 주입은 이 원칙을 따르는 방법 중 하나다. - 새로운 할인 정책을 개발하고, 적용하려고 하니 클라이언트 코드도 함께 변경해야 했다. - 왜냐하면 기존 클라이언트 코드( OrderS..

지금까지의 흐름을 정리해보자. 1. 새로운 할인 정책 개발 2. 새로운 할인 정책 적용과 문제점 3. 관심사의 분리 4. AppConfig 리팩터링 5. 새로운 구조와 할인 정책 적용 6. 새로운 할인 정책 개발 다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없음 새로운 할인 정책 적용과 문제점 새로 개발한 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체도 함께 변경해야함 주문 서비스 클라이언트가 인터페이스인 DiscountPolicy 뿐만 아니라, 구체 클래스인 FixDiscountPolicy 도 함께 의존 → DIP 위반 (추상화에만 의존해야 하는데 구현체 까지도 의존 한 상태) 관심사의 분리 - 애플리케이션을 하나의 공연으로 생각 - 기존..

새로운 구조와 할인 정책 적용 - 처음으로 돌아가서 정액 할인 정책을 정률% 할인 정책으로 변경해보자. - FixDiscountPolicy RateDiscountPolicy - 어떤 부분만 변경하면 되겠는가? AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. 그림 - 사용, 구성의 분리 그림 - 할인 정책의 변경 - FixDiscountPolicy RateDiscountPolicy 로 변경해도 구성 영역만 영향을 받고, 사용 영역은 전혀 영향을 받지 않는다. 할인 정책 변경 구성 코드 - AppConfig 에서 할인 정책 역할을 담당하는 구현을 FixDiscountPolicy → RateDiscountPolicy 객체로..

AppConfig 리팩터링 - 현재 AppConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 안보인다. 기대하는 그림 리팩터링 전 - 중복을 제거하고, 역할에 따른 구현이 보이도록 리팩터링 하자. package hello.core; import hello.core.discount.FixDiscountPolicy; import hello.core.discount.RateDiscountPolicy; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import hello.core.member.MemoryMemberRepository; import hello.core.order.OrderService; i..

관심사의 분리 - 애플리케이션을 하나의 공연이라 생각해보자. 각각의 인터페이스를 배역(배우 역할)이라 생각하자. 그런데! - 실제 배역 맞는 배우를 선택하는 것은 누가 하는가? - 로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할지 줄리엣 역할을 누가 할지는 배우들이 정하는게 아니다. - 이전 코드는 마치 로미오 역할(인터페이스)을 하는 레오나르도 디카프리오(구현체, 배우)가 줄리엣 역할(인터페이스)을 하는 여자 주인공(구현체, 배우)을 직접 초빙하는 것과 같다. - 디카프리오는 공연도 해야하고 동시에 여자 주인공도 공연에 직접 초빙해야 하는 다양한 책임을 가지고 있다. 관심사를 분리하자 - 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다. - 디카프리오는 어떤 여자 주인공이 선택되더라도 똑..