개발자되기 프로젝트

1. 클래스로 빈을 찾았는데 같은 타입의 빈이 여러개면??? 이름을 지정해주면 된다 ㅋㅋ as.getBeansOfType()사용하면 해당 타입의 모든 빈 조회가능 중복상황을 만들어 주기 위해 내부 클래스에 SameBeanConfig를 만들어주었다. 만약 클래스로 찾았는데 중복된다면 NoUniqueDefinitionException이 발생한다. public class ApplicationContextSameBeanFindTest { AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SameBeanConfig.class); @Test @DisplayName("타입으로 조회 시 같은 타입이 둘 이상 있으면, 중복 오류가..

1. 스프링 컨테이너에서 스프링 빈을 찾는 가아아아아아장 기본적인 방법 ac.getBean(빈의 이름, 타입) ac.getBean(타입) 찾을 대상이 없으면 예외터짐 2. 이름으로 조회하기 ac.getBean(빈 이름, 타입) MemberService의 구현체는 MemverServiceImpl, MemberServiceImpl이 빈으로 등록되어 있어야 한다. @Test @DisplayName("빈 이름으로 조회") void findBeanByName(){ MemberService memberService = ac.getBean("memberService", MemberService.class); assertThat(memberService).isInstanceOf(MemberServiceImpl.clas..

스프링에 등록된 빈을 확인할 수 있나??? 1. 스프링에 등록된 빈을 확인해보자. 아래와 같이 테스트 코드를 작성해 주자. AnnotationConfigApplicationContext(AppConfig.class)를 통해 AppConfig에서 @Bean이 붙은 메서드의 반환 객체를 bean으로 등록한다. Bean으로 등록될 객체 : AppConfig, MemberServiceImpl, OrderServiceImpl, MemoryMemberRepository, RateDiscountPolicy. public class ApplicationContextInfoTest { AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationConte..

1. 스프링 컨테이너 생성 : 어떻게 생성되는겨~ ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 일반적으로 ApplicationContext를 스프링 컨테이너라고 부름. ApplicationContext는 인터페이스 : 오? 다형성~~? 스프링 컨테이너는 XML으로 할수도 있고, @Annotation기반의 자바 설정 클래스로도 가능 자바로 하는 경우 AnnotationConfigApplicationContext(~) --> 편함 ㅎㅎ 파라미터로 AppConfig.class를 넣어줌 ㅋㅋ AnnotationConfigApplicationContext는 ApplicationContext의 구현체임. 2. 스프링..

야아아압 1. AppConfig를 스프링 기반으로 전환! @Configutarion : 설정 정보에 적용 @Bean : 스프링 컨테이너에 bean으로 등록됨. 스프링 컨테이너에 등록 될 때 각 메서드의 이름으로 등록된다. @Configuration public class AppConfig { @Bean public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } @Bean public OrderService orderService(){ return new OrderServiceImpl(memberRepository(), discountPolicy()); } @Bean public MemoryMemberRe..

1. 제어의 역전(Inversion of Control) 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성, 연결, 실행함 즉, 구현객체가 프로그램의 제어 흐름을 스스로 조종. 주우우욱 작성하다가 필요한거 있으면 호출해서 쓰고.. 자연스러움 근데 AppConfig이후 구현 객체는 온전히 자신의 로직을 실행하는 역할만 가짐. 프로그램의 제어 흐름에 대한 권한은 AppConfig가 가져감. 프로그램의 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라 함. 2. 프레임워크 vs 라이브러리 프레임워크가 내가 작성한 코드를 제어, 대신 실행함. 내가 제어의 흐름을 담당하면? 그건 라이브러리임. 3. 의존관계 주입(DI) 의존관계는 "정적인 클래스 의존 관계"와 "..

이전에 할인 정책을 바꾸려다보니 DIP, OCP위반이 발생하여 AppConfig를 도입하여 관심대상을 분리하였다. 1. 사용, 구성의 분리 할인 정책은 변경하기 위해서는 구성 영역의 코드만 변경해 주면 된다. 변경 전 변경 후 2. AppConfig 수정 public class AppConfig { public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } public OrderService orderService(){ return new OrderServiceImpl(memberRepository(), discountPolicy()); } private MemoryMemberRepository memb..

현채 AppConfig는 중복이 있고, 역할에 따른 구현이 잘 안보인다. public class AppConfig { public MemberService memberService(){ return new MemberServiceImpl(new MemoryMemberRepository()); } public OrderService orderService(){ return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy()); } } 아래와 같이 역할과 구현이 분명히 보이도록 수정해 주자. MemberRepository가 어떤 구현체를 사용할지 분명하게 보임 --> 변경 용이 DiscountPolicy가 어떤 구현체를 사용할..