개발 성장 일기 :)

* 빈 생명주기 콜백 시작 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다. 스프링을 통한 초기화 작업과 종료 작업은 총 3가지가 있다. 1. 인터페이스 2. 설정 정보에 초기화 메서드, 종료 메서드 지정 3. @PostConsturct, @PreDestroy 에노테이션 지원 결과적으로 @PostConstruct, @PreDestroy 에노테이션을 사용하자 ! 코드를 고칠 수 없는 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 initMethod, destroyMethod를 사용하자. 스프링 빈은 간단한 라이프사이클을 가진다. * 객체 생성 -..

Autowired는 타입으로 조회한다. 이 때, DiscoutPolicy 타입의 2개가 모두 스프링빈으로 선언했다면? 1. DiscountPolicy 하위타입인 FixDiscoutPolicy 2. DiscountPolicy 하위타입인 RateDiscountPolicy -> NoUniqueBeanDefinitionException 오류가 발생한다. 의존관계 자동 주입 시, 똑같은 타입의 스프링 빈이 있을 때 해결하는 3가지 방법 1. @Autowired 필드 명 매칭 2. @Qualifier 3. @Primary 1. @Autowired 필드 명 매칭 @Autowired 는 처음 타입을 매칭하고, 여러 빈이 있으면 필드이름, 파라미터 이름 으로 빈을 추가 매핑한다. 따라서, 주입할 대상의 필드명을 변경시켜..

의존관계 주입은 크게 4가지 방법이 있다. 1. 생성자 주입 2. 수정자 주입(setter 주입) 3. 필드 주입 4 일반 메서드 주입 결론부터 말하자면 생성자주입을 권장한다. 생성자 주입을 권장하는 이유! * 불변 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변해야 한다.) 수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 한다. 누군가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다. 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다. *누락 프레임워크..

모든 자바 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸린다. 그래서 꼭 필요한 위치부터 탐색하도록 시작위치를 지정할 수 있다. basePackages: 탐색할 패키지의 시작 위치를 정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다. ex. basePackages = "hello.core" basePackagesClasses : 지정한 클래스의 패키지를 시작 위치로 지정한다. 디폴트는 @ComponentScan 이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다. * 권장 하는 방법 - 설정 정보의 클래스 위치를 프로젝트 최상단에 두고, 패키치 위치를 지정하지 않는 것을 추천한다. ex. 아래와 같은 프로젝트 구조인 경우, com.hello com.hello.service com.hello...

스프링 빈으로 등록할 때마다, @Bean 을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다. 등록할 스프링 빈이 많으면 일일이 등록하기도 힘들고 누락되는 경우도 생긴다. -> 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 컴포넌트 스캔을 사용하기 위해서는 @ComponentScan 을 설정 정보에 붙여주면 된다. 기존의 AppConfig와는 다르게 @Bean으로 등록한 클래스가 하나도 없다! - 컴포넌트 스캔을 사용하면 @Configuration 이 붙은 설정 정보도 자동으로 등록되기 때문에, ( @Configuration 이 컴포넌트 스캔의 대상이 된 이유도 @Configuration 소스코드를 열어보면 @Component 애노테이션이 붙어있기 ..

AppConfig 를 보면 1. MemberSerivce 호출 2. MemberRepository 호출 3. MemoryMemberRepository 호출 4. OrderService 호출 5. MemberRepository 호출 discountPolicy 호출 6. MemoryMemberRepositoy 호출 7. FixDiscountPolicy 호출 -> 결과적으로 MemoryMemberRepository 가 2번 호출되는 것 처럼 보인다. -> 하지만, 출력해보면 1번만 호출되는 것을 확인해 볼 수 있을 것이다. -> @Configuration 스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다. 저 자바..

웹 애플리케이션과 싱글톤 스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다. 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 물론 웹이 아닌 애플리케이션 개발도 얼마든지 개발할 수 있다. 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 클라이언트들이 서비스를 요청할때마다 객체를 생성해 주는 것을 비효율적이다. 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다. - 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다! -> 메모리 낭비가 심하다 - 해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. -> 싱글톤 패턴 싱글톤 패턴 클래스의 인스턴스가 딱 1개만 생성되는 것을..

1. BeanFactory 스프링 컨테이너의 최상위 인터페이스다. 스프링 빈을 관리하고 조회하는 역할을 담당한다. getBean() 을 제공한다. 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다. 2. ApplicationContext BeanFactory 기능을 모두 상속받아서 제공한다. 빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데, 그러면 둘의 차이가 뭘까? 애플리케이션을 개발할 때는 빈은 관리하고 조회하는 기능은 물론이고, 수 많은 부가기능이 필요하다. ApplicationContext는 BeanFactory의 기능을 상속받는다. ApplicationContext는 빈 관리기능 + 편리한 부가 기능을 제공한다. BeanFactory를 직접 사용..

부모 타입으로 조회하면, 자식 타입도 함께 조회한다. 그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회한다. 1. 부모 타입으로 조회시, 자식이 둘 이상 있으면 중복 오류가 발생한다. - ac.getBean(DiscountPolicy.class) 로 조회하면 중복오류 발생 -> 빈 이름으로 조회하거나, ac.getBean("rateDiscountPolicy", DiscountPolicy.class) -> 특정 하위 타입으로 조회한다. ( 추천하는 방법은 아님 ) 2. 부모 타입으로 모두 조회해보기.

* 스프링 빈 타입으로 조회 하는 법 ac.getBeansOfType()