오늘의하루

request 웹 요청이 들어오고 나갈때까지 유지 되는 스코프 클라이언트 A가 요청하면 A전용 객체가 만들어지고 서비스에서 A 객체를 조회할 수있으며 응답으로 요청이 종료되면 해당 스코프의 객체는 소멸한다. Prototype은 매번 새로운 객체를 만들지만 request는 요청이 들어오면 생성하고 응답하기 전까지 유지된다. Prototype은 소멸전 콜백이 안되지만 request의 경우 소멸전 콜백이 가능하다. 문제. 서버 실행시에는 요청이 없기 때문에 request scope의 빈을 주입받을 수 없다. 만약 의존관계 주입시 request scope의 빈을 주입한다고 가정했을때 어떻게 해결할 수 있을까? ObjectProvider를 이용하여 빈의 생성을 지연 시킬 수 있다. @Component @Scope..

Bean Scope Bean이 존재할 수 있는 범위를 뜻한다. Singleton Bean의 기본 스코프이며 스프링 컨테이너의 시작부터 종료까지 유지되는 가장 넓은 범위의 스코프이다. Prototype 스프링 컨태이너는 Prototype Bean의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않고 반환하는 가장 짧은 범위의 스코프이다. 초기화 콜백까지는 불러주지만 소멸전 콜백은 해주지 않는다. 종료 메서드의 경우 직접 호출해야한다. 만약 Singleton내부에서 Prototype을 사용하려면? 이 질문의 의도는 여러명의 클라이언트가 요청을 보낼때 마다 Prototype을 새롭게 만들어서 주입이 가능하냐는 말이다. 만약 기존에 의존관계를 주입하듯이 하면 처음 주입 받은 Prototype이 Singlet..

스프링 빈의 이벤트 라이프 사이클 스프링 컨테이너 생성 > 스프링 빈 생성 > 의존 관계 주입 > 초기화 콜백 > 사용 > 소멸전 콜백 > 스프링 종료 참고 사항 생성자 주입의 경우 빈 생성 단계에서 주입되고 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 코드만 보고 의존관계를 쉽..

객체 지향 설계에서 DIP는 의존 관계 역전 원칙을 의미한다. 프로그래머는 추상화에 의존해야하며 구체화에 의존하면 안되는다는 말이다. public class Test{ TestInterface ti = new TestObject(); } 위와 같이 다형성을 이용하여 작성하면 DIP를 위반하는 행위가 된다. 현재 Test 클래스는 인터페이스와 구현체 두가지 모두에 의존하고 있는 상황이다. 이를 해결 하기 위해서는 Test클래스는 추상화만 의존하게 만들어줘야 한다. public class Test{ // 현재 Test 클래스는 추상화에만 의존하고 있다. TestInterface ti; Test(TestInterface ti){ this.ti = ti; } } public class AppConfig{ // ..

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