Study

스프링 빈의 라이프 사이클 스프링 빈은 간단하게 다음과 같은 라이프사이클을 가진다. ➡️ 객체 생성 -> 의존관계 주입 스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다. 그런데 개발자가 의존관계 주입이 모두 완료된 시점을 어떻게 알 수 있을까? 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다. 따라서 안전하게 종료 작업을 진행할 수 있다. 스프링 빈의 전체 이벤트 라이프사이클 ➡️ 스프링컨테이너생성 -> 스프링빈생성 -> 의존관계주입..

수동 빈 등록 (컴포넌트 애노테이션이 붙은 것들을 제외하고) @Bean을 통해 등록되는 것. AppConfig와 같이 자바 설정파일을 추가하여 수동 빈 등록하면 된다. 수동 빈 등록은 언제 사용하면 좋을까? 1. 기술 지원 빈 애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있다. 업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다. 업무 로직은 숫자도 매우 많고 유사한 패턴을 가지고 있다. 보통 문제가 발생해도 어떤 곳에서 문제가 발생했는지 명확하게 파악하기 쉽다. 기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다...

의존관계 자동 주입 생성자 주입 생성자를 통해서 의존관계를 주입 받는 방식 불변, 필수 의존관계에 사용 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입된다. 수정자 주입 선택, 변경 가능성이 있는 의존관계에 사용 필드 주입 필드에 바로 주입하는 방법 코드가 간결하지만 추후 변경이 불가능해 테스트 하기 어렵다는 단점이 있다. 되도록이면 사용하지 말고 테스트 코드에서만 사용하도록 하자 일반 메서드 주입 일반 메서드를 통해 주입 받을 수 있지만 일반적으로 잘 사용하지 않는다 옵션처리 주입할 스프링 빈이 없어도 동작해야 할 때가 있다. 이럴때 옵션값을 이용해 처리하면 된다. @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨 org...

컴포넌트 스캔 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. @Configuration @ComponentScan( excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class)) public class AutoAppConfig { } 컴포넌트 스캔은 이름 그대로 @Component 애노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 등록한다. 이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다. 빈 이름 기본 전략: MemberServiceImpl 클래스 -> memberServiceImpl 빈 이름 직접 지정: 만약 스프링 빈의 이름을..

싱글톤 패턴 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴 private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막고 getInstance 메서드를 제공해서 객체 인스턴스를 return 한다. 주의점 : 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 stateful하게 설계하면 안된다. 문제점 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다 자식 클래스를 만들기 어렵다 유연성이 떨어진다 의존관계상 클라이언트가 구체 클래스에 의존 - DIP 위반 더보기 의존관계 역전 원칙 : DIP, Dependency inversion principle 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 구현 클래스에 의존하지 말고..