@Configuration은 사실 싱글톤을 위해 존재하는 것이다. 그런데 이상한 점이 있다. 이전에 작성했던 AppConfig 코드를 다시 확인해보자. @Configuration public class AppConfig { @Bean public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } @Bean public MemberRepository memberRepository() { return new MemoryMemberRepository(); } @Bean public OrderService orderService(){ return new OrderServiceImpl(memberRepository(..
싱글톤 패턴이던 스프링 같은 싱글톤 컨테이너를 사용하던, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 즉, 무상태(stateless)로 설계해야 한다. 특정 클라이언트에 의존적인 필드가 있으면 안된다. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. 가급적 읽기만 가능해야 한다. 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal...등을 사용해야 한다. 스프링 빈의 필드에 공유 값을 설정하면 큰 장애가 발생할 수 있다.
싱글톤 컨테이너에 대해 알아보자. 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 지금까지 우리가 학습한 스프링 빈이 싱글톤으로 관리되는 빈이다. 싱글톤 컨테이너 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. 이전에 설명한 컨테이너 생성 과정을 보면 컨테이너 객체를 하나만 생성해서 관리한다. 즉, 스프링 컨테이너는 싱글톤 컨테이너 역할을 하는 것이다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다. 스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다. 다음과 같은 테스트코드를 작성해 직접 확인해보자. @Test @Display..
스프링에 왜 객체 지향 이야기가 나올까? 스프링은 DI(Dependency Injection)을 통해서 OCP, DIP를 가능하게 지원한다. DI는 의존관계 주입, 의존성 주입이라고 하며, DI 컨테이너를 제공한다. DI 컨테이너는 자바의 객체들을 컨테이너 안에 넣어두고 이 안에서 의존관계를 연결해주고 주입해주는 기능을 제공하는 것이다. 이것을 활용하여 클라이언트 코드의 변경 없이 기능을 확장할 수 있다. 이제까지의 포스팅을 정리해보면, 모든 설계에 역할과 구현을 분리할 필요가 있다. 애플리케이션 설계도 공연을 설계 하듯이 배역(인터페이스, 역할)만 만들어두고, 배우(구현)는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계이다. 이것이 가능하려면 다형성 뿐만아니라, SOLID원칙도 ..
들어가기에 앞서, 먼저 스프링에 대해 잠깐 알아보자. 스프링의 생태계 스프링은 단순한 하나의 개념이 아니라, 여러 가지 기술의 모음이라 볼 수 있다. 위의 그림을 살펴보면, 먼저 스프링의 가장 핵심이 되는 스프링 프레임워크, 여러 스프링 기술들을 편리하게 사용할 수 있도록 도와주는 스프링 부트는 스프링의 필수적인 요소이다. 스프링 데이터는 데이터베이스를 편리하게 사용할 수 있도록 도와주는 것이며, 제일 많이 사용하는 것은 스프링 데이터 jpa이다. 스프링 세션은 세션 기능을 편리하게 사용할 수 있도록 도와주는 것이며, 스프링 시큐리티는 보안과 관련된 것, 스프링 Rest Docs는 API 문서화를 편리하게 해주는 것이다. 마지막으로 스프링 배치는 배치 처리에 특화된 기술이며, 스프링 클라우드는 클라우드에..