♪ 학습 내용 의동일한 타입의 빈이 두개 이상일 경우에 의존관계 자동 주입 / 애노테이션 생성 * 여러 동일 타입 빈 Autowired는 컨테이너에서 빈을 찾아 자동으로 주입해준다는 것을 학습했다. 이때 빈을 찾는 방식은 타입으로 조회이다. ac.getBean(DiscountPolicy.class); 와 비슷하다. 그렇다면 컨테이너에 동일한 타입의 스프링 빈이 두개 이상이라면 어떻게 될까?? 실행 시 오류가 발생한다 어떻게 해결할 수 있을까?? 만약 다음과 같이 하위 타입으로, 구현에 의존한다면 오류는 사라질 것이다 @Autowired public OrderServiceImpl(MemberRepository memberRepository, RateDiscountPolicy discountPolicy) {..

♪ 학습 내용 의존관계 주입 옵션처리 / 생성자 주입 / 롬복 라이브러리 설정 및 이용 * 옵션처리 @Autowired 이용 시에 해당하는 자동 주입 대상이 없으면 오류가 발생한다 하지만 개발하다보면 빈 없이도 동작해야할 때가 가끔 있기 때문에 따로 처리가 필요 세가지 방법!! - Autowired의 required 값을 false로 설정한다 (디폴트는 true) @Autowired(required = false) public void setNoBean(Member member){ System.out.println(member); } 위의 Member클래스는 스프링에서 관리하는 클래스가 아니기 때문에 빈으로 등록되어있지 않고 자동의존관계 주입도 불가하다. 하지만 Autowired의 required 옵션의..

♪ 학습 내용 의존관계 주입 방법 ** 의존관계 주입 방법 앞에서는 빈을 자동 등록하고 @Autowired를 이용해 의존관계 자동 주입하는 것 배웠다 이 방법을 통해 의존관계 주입하는 방법에는 4가지가 있다 - 생성자 주입 - 수정자 주입 - 필드 주입 - 일반 메서드 주입 * 생성자 주입 여태까지 학습하면서 했던 것들이 바로 생성자 주입..!! 스프링 컨테이너에서 스프링 빈을 등록하기 위해 객체를 생성, 이때 생성자로 호출하여 생성하고 반환하기 때문에 그 과정에서 의존관계를 주입한다 따라서 생성자 주입은 필수성을 지닌다 또한 생성자 주입은 생성자 호출할 시에 딱 한번만 호출되기 때문에(별도 설정을 만들지않는 한) 불변성을 가진다 만약에 생성자가 한개만 있다면 @Autowired 애노테이션을 생략해도 무..

* 프로세스 및 스레드 개념 프로세스는 실행 중인 하나의 애플리케이션이다. 만약에 크롬 브라우저를 두 개 띄워놨다면, 두개의 Chrome 프로세스가 생성된 것이라고 이해 멀티 태스킹은 두 가지 이상의 작업을 동시에 처리하는 것을 의미한다. 예로 미디어 플레이어는 동영상 재생과 소리 재생을 동시에 처리하는데 이를 가능하게 하는 것이 바로 멀티 스레드이다. 스레드란 한 가닥의 실 이라는 의미로, 하나의 스레드는 하나의 코드 실행 흐름이다. 미디어 플레이어에서 동영상 재생과 소리 재생은 각각 하나의 스레드( 실행 흐름 )라고 보면 될 거 같다. 멀티 프로세스는 자신의 메모리를 할당 받아 실행하기 때문에 독립적이다 ex ) 워드와 ppt를 실행 중에 워드에 오류 생겨도 ppt는 정상 작동한다 반면에 멀티 스레드..

♪ 학습 내용 컴포넌트 스캔 필터 및 중복 등록 * 컴포넌트 스캔 필터 컴포넌트 스캔의 필터( Filter ) 를 이용해 내가 원하는 대상을 컴포넌트 스캔 대상에 추가하거나 제외시킬 수 있다. 임의로 만든 MyIncludeComponent 와 MyExcludeComponent 애노테이션을 각각 BeanA 와 BeanB클래스에 적용 FilterType.ANNOTATION 은 애노테이션과 관련된 필터를 의미한다. - includeFilters 에 @MyIncludeComponent 추가했다 - excludeFilters 에 @MyExcludeComponent 추가했다 assertThat(beanA).isNotNull(); //실행 결과 : 통과 //beanA는 @MyIncludeComponent 애노테이션이..

♪ 학습 내용 컴포넌트 스캔 및 의존관계 자동 주입 * 컴포넌트 스캔 여태까지 스프링 컨테이너에 빈을 등록하기 위해서는 설정 정보에 @Bean을 이용 만약 스프링 빈으로 등록할 게 수천 수만가지라면 ? 컴포넌트 스캔( @ComponentScan ) 을 이용하면 더 간단하게 빈 등록할 수 있다. 설정 정보에 @ComponentScan을 붙이고 Bean으로 등록할 클래스 앞에 @Component를 붙여준다 그러면 @ComponeneScan에서 @Component 을 스캔 후 빈으로 등록한다. 기본적으로 @Configuration 도 내부적으로 @Component를 포함하고 있기 때문에 탐색 조건에 해당한다 앞서 만들었던 설정 정보(수동 Bean 등록)랑 겹치면 안되니까 스캔 대상에서 제외했다. * 의존관계 ..

♪ 학습 내용 싱글톤 방식의 주의점과 @Configuration - CGLIB * 싱글톤 주의 스프링 컨테이너 같은 싱글톤 컨테이너를 이용하든 뭘 하든 싱글토 방식은 무상태로 설계해야한다 클라이언트에(가) 의존적인 필드, 값을 변경할 수 있는 필드 x 가급적 자바에서 공유되지 않는지역변수 파라미터등을 사용 무슨 말이냐? 이해하기 위해서 아래 Test를 해봄 웹 애플리케이션 수많은 요청이 동시에 들어오고, 스프링 컨테이너를 통해 싱글톤 유지되는 것을 저번 학습에서 배웠다 그렇기 때문에 여기서 statefulService1 과 statefulService2는 같은 객체 인스턴스를 참조한다. A사용자가 10000원을 주문하고 getPrice()를 통해 주문 금액을 반환 받으려고 하는데 그 사이에 B사용자가 2..

♪ 학습 내용 싱글톤 패턴 및 싱글톤 컨테이너 * 싱글톤 웹 애플리케이션은 특성상 여러 고객이 동시에 요청을 한다 만약 DI컨테이너인 AppConfig에서 여러 고객이 동시에 요청을 한다면 각 요청마다 새로운 객체 인스턴스를 생성해버린다 매우 낭비..!! 싱글톤 패턴 : 객체가 딱 1개만 생성되고 공유하도록 설계 - static 영역에 객체를 1개 미리 생성해둔다 - 그 객체는 getInstance()메서드를 통해서만 접근 가능 - private으로 생성자 제한. 외부에서 new 연산자로 객체를 생성하지 못한다 즉, 여러 호출이 들어와도 같은 객체 인스턴스를 반환. 싱글톤 패턴. 싱글톤 문제점 - 코드가 늘어남 - 구현에 의존 ( 클라이언트에서 구체클래스.getInstance를 사용하게 되는) DIP위반..

♪ 학습 내용 XML 기반 스프링 컨테이너 생성 빈 설정 메타 정보 BeanDefinition * 스프링 설정 형식 스프링 컨테이너는 설정 정보를 다양한 형식으로 받아들일 수 있다. ApplicationContext(스프링 컨테이너) 아래에 이를 구현하는 다양한 형식의 설정 정보 XxxApplicationContext는 Xxx을 설정 정보로 사용하는 ApplicationContext이다 ex) GenericXml ApplicationContext는 GenericXml, 구체적으로는 appConfig.xml을 설정 정보로 사용하는 ac * XML기반 설정 사용해왔던 AppConfig.java 와 구조만 다르지, 거의 똑같다 xml 기반은 스프링 부트를 사용하면서 잘 사용하지 않는 추세 따라서 이렇게 스프링..

♪ 학습 내용 동일 타입과 상속 관계에 따른 스프링 빈 조회 BeanFactory , Application Context * 동일 타입 빈 조회 둘 이상의 동일 타입 스프링 빈이 있을 때 타입으로 조회 시 오류 발생 해결하기 위해 빈 이름을 지정한다 (너무도 당연한 얘기일지도..) 빈 이름은 따로 지정하지 않는 한 @Bean 메서드의 이름이다. * 상속 관계의 스프링 빈 조회 부모 타입을 조회 --> 자식 타입도 조회 static import를 사용하여 앞에 Assertions 생략 assertThrowos( 예외, 로직); == 로직을 실행했을 때 해당 하는 예외가 터질 경우 통과이다 위 사진에서 통과 했다는 것은 DiscountPolicy를 타입으로 조회하였을 때 둘 이상의 스프링 빈이 조회됐다는 것..