오늘의하루

스프링 빈의 이벤트 라이프 사이클 스프링 컨테이너 생성 > 스프링 빈 생성 > 의존 관계 주입 > 초기화 콜백 > 사용 > 소멸전 콜백 > 스프링 종료 참고 사항 생성자 주입의 경우 빈 생성 단계에서 주입되고 setter와 필드 주입은 의존 관계 주입 단계에서 주입된다. 객체의 생성과 객체의 초기화는 분리하여 설계하는 것이 좋다. 콜백하는 방법 인터페이스 InitializingBean, DisposableBean을 구현하면 된다. 현재는 잘 사용되지 않는다. 스프링에 의존적이며 메서드명을 지정할 수 없는 단점이 있다. 설정 정보에서 초기화, 종료 메서드 지정 빈을 수동으로 등록할 때 사용된다. @Bean(InitMethod = "초기화메서드명", destoryMethod = "종료메서드명") destor..

의존관계 주입 @Autowired는 기본적으로 등록된 빈의 타입으로 주입한다. 스프링이 빈을 모두 등록한 후 의존관계를 주입해준다. 기본적으로 주입할 대상이 빈에 등록되지 않으면 오류가 발생하며, 이를 막고 싶다면 @Autowired(required=false)로 지정하면 된다. 의존 관계 주입 4가지 방법 생성자 주입 생성자 호출 시점에서 딱 1번만 호출되는 것을 보장된다. 불변, 필수 의존 관계에서 사용한다. 생성자가 하나라면 @Autowried를 생략할 수 있다 스프링이 빈을 등록할때 결국 인스턴스화 할때 new 연산자를 사용하기 때문이다. 수정자 주입(setter 주입) 선택, 변경 가능성이 있는 의존관계에서 사용한다. 필드 주입 (권장하지 않는다.) 코드가 간결하지만 순수 자바 테스트가 힘들다는..

ComponentScan은 쉽게 말하면 자동으로 빈을 등록하는 기능을 말한다. @ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈에 등록한다. 이때 등록되는 빈의 이름은 클래스명을 사용하되 앞글자만 소문자로 사용한다. 만약 이름을 변경하고 싶다면 @Component("이름")으로 지정할 수도 있다. 빈객체는 해당 Component가 붙은 클래스가 된다. 생성자에 @Autowired를 지정하면 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다. 이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다. 같은 타입이 둘 이상이라면 오류가 발생한다. (해결 가능) 생성자의 매개변수가 부모타입이라면 다형성으로 자식타입을 찾아서 주입한다. @ComponetScan의 경우 기..

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리한다. 싱글톤의 문제 코드가 많다. DIP를 위반하고 OCP를 위반할 가능성이 크기 때문에 유연성이 떨어진다. 테스트가 어렵다. 진짜 주의해야 하는 사항 스프링이 싱글톤을 만들어줘도 이것들은 주의해야한다. 특정 클라이언트에 의존적인 필드가 있으면 안된다. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. 가급적 읽기만 가능해야한다. 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal등을 사용해야한다.

BeanFactory 스프링 컨테이너의 최상위 인터페이스 스프링 빈을 관리하고 조회하는 역할을 담당 ex) getBean()을 제공하고 있다. ApplicationContext BeanFactory 기능을 모두 상속받아서 제공한다. 빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데 둘의 차이는 무엇일까? - 애플리케이션을 개발할때는 빈은 관리하고 조회하는 기능뿐만 아니라 수많은 부가기능이 필요하다. - 메세지 소스를 활용한 국제화 기능 ex) 한국에서 들어오면 한국어, 영어권에서 들어오면 영어 - 환경변수 ex) 로컬, 개발, 운영등을 구분해서 처리할 수 있게 한다 - 애플리케이션 이벤트 ex) 이벤트를 발행하고 구독하는 모델을 편리하게 지원 - 편리한 리소스 조회 ex) 파일, 클래스패..

제어의 역전 IoC (Inversion of Control) 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 말한다. 프레임 워크 vs 라이브러리 프레임워크가 내가 작성한 코드를 제어하고 대신 실행하면 그것은 프레임워크이다.(예 : JUnit) 반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 라이브러리이다. 의존관계 주입 DI (Dependency Injection) 정적인 클래스 의존 관계와 실행 시점에 결정되는 동적인 객체 의존관계 둘을 분리해서 생각해야 한다. 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고 동적인 객체 인스턴스 의존과계를 쉽게 변경 할수 있다. 정적인 클래스의 의존관계 클래스가 사용하는 import 코드만 보고 의존관계를 쉽..

SRP : 단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다. 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다. OCP : 개방-폐쇄 원칙 스프링 컨테이너가 OCP 문제점을 해결해준다. 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 다형성을 활용하면 가능하다. 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현 역할과 구현의 분리를 생각하면 쉽다. LSP : 리스코프 치환 원칙 프로그램 객체는 하위 타입의 인스턴스로 바꿀수 있어야 한다. ISP : 인터페이스 분리 원칙 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다. 인스터페이스 명확해지고, 대체 가능성이 높아진다. DIP : 의존관계 역..