백엔드 개발자, 나단

이전 편에서는 컴포넌트 스캔을 통해 빈을 자동 등록하고, 생성자에 @Autowired를 붙여 의존성을 주입하는 기본 방식을 살펴봤다. 이번 편에서는 스프링이 제공하는 다양한 의존관계 주입 방법들을 정리한다.1. 생성자 주입가장 권장되는 방식@Componentpublic class OrderServiceImpl implements OrderService { private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discoun..

@SpringBootApplication // 내부에 @ComponentScan 포함public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); }}이전 편에서는 @ComponentScan을 통해 빈을 자동 등록하는 기본 기능과 @Autowired를 통한 생성자 주입까지 살펴봤다. 이번 편에서는 컴포넌트 스캔의 탐색 위치, 스테레오타입 어노테이션, 필터 사용법, 빈 충돌 처리 방식까지 더 깊게 들어가본다. 1. 컴포넌트 스캔의 탐색 위치 @ComponentScan은 어디서부터 클래스를 스캔할지를 정할 수 있다.@ComponentScan(..

스프링 설정을 직접 수동으로 등록하던 방식은 프로젝트가 커질수록 유지보수가 어려워진다. 그래서 등장한 것이 컴포넌트 스캔(Component Scan) 이다. 이 기능을 활용하면, 특정 어노테이션이 붙은 클래스들을 자동으로 스프링 컨테이너에 등록할 수 있다. 이번 편에서는 컴포넌트 스캔이 어떤 역할을 하고, 이를 통해 어떻게 의존 관계를 자동 주입받을 수 있는지 살펴본다. 컴포넌트 스캔이란?스프링이 클래스패스를 스캔해서 @Component가 붙은 클래스를 자동으로 스프링 빈으로 등록해주는 기능이다.@Configuration@ComponentScan( excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Config..

지난 편에서는 스프링이 어떻게 싱글톤 객체를 자동으로 관리해주는지, 그리고 싱글톤 설계 시 주의할 점들을 다뤘다.이번 편에서는 @Configuration이 어떻게 실제로 싱글톤을 보장하는지, 그리고 그 뒤에 숨어 있는 바이트코드 조작의 비밀에 대해 살펴보겠습니다람쥐~1. AppConfig의 의도와 실제 호출 다음은 우리가 일반적으로 작성하는 AppConfig 코드입니다.@Configurationpublic class AppConfig { @Bean public MemberService memberService() { System.out.println("call AppConfig.memberService"); return new MemberServiceImpl(membe..

스프링 프레임워크는 대부분의 빈을 싱글톤으로 관리합니다. 이번 편에서는 왜 싱글톤을 사용하는지, 직접 구현한 싱글톤 패턴과의 차이점은 무엇인지, 그리고 싱글톤 설계 시 주의할 점은 무엇인지에 대해 하나하나 짚어보겠습니다. 1. 웹 애플리케이션과 객체 생성의 문제 웹 애플리케이션에서는 수많은 사용자가 동시에 요청을 보냅니다. 예를 들어 A, B, C 사용자가 동시에 요청을 보내면 객체가 3개 생성되는 상황이 발생합니다. 이런 구조는 성능과 메모리 측면에서 매우 비효율적입니다. 객체를 매번 생성하는 것은 메모리 낭비와 GC 오버헤드로 이어지며, 결국 서버의 응답 속도까지 느려집니다.2. 해결책: 싱글톤 패턴객체를 매번 생성하지 않고 하나의 인스턴스를 공유하면 어떨까요? 이를 해결하는 방식이 바로 싱글톤 패턴..

스프링 컨테이너의 생성, 빈 등록과 조회까지 알아봤다.이번 편에서는 빈 조회의 다양한 케이스, 스프링 컨테이너가 제공하는 추가 기능들, 그리고 그 핵심을 관통하는 BeanDefinition 메타정보에 대해 정리해본다.요구사항 빈이 상속 관계일 때의 조회 방법을 알고 싶다.스프링 컨테이너가 제공하는 다양한 기능을 활용하고 싶다.설정 방식이 달라도 일관된 메커니즘으로 빈을 다루고 싶다.문제점 부모 타입으로 조회할 경우 자식이 여러 개면 어떤 게 반환되는지 헷갈릴 수 있다.단순한 빈 관리 외에도 다양한 부가기능을 어떻게 활용할지 모르겠다.자바, XML 등 설정 방식이 다른데 스프링이 어떻게 하나로 관리할 수 있는지 이해가 안 된다. 개선 방향: 다양한 조회 방식과 BeanDefinition 이해하기 1. 부모..

스프링 컨테이너에 빈이 잘 등록되었는지 확인하고 싶다면? 바로 빈 조회 테스트를 통해 확인할 수 있다. 요구사항등록된 빈 목록을 확인하고 싶다.특정 빈을 이름 혹은 타입으로 가져오고 싶다.스프링 내부에서 사용 중인 빈과 구분해서 보고 싶다.빈 조회 예제AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);@Test@DisplayName("모든 빈 출력하기")void findAllBean() { String[] beanNames = ac.getBeanDefinitionNames(); for (String name : beanNames) { Object bean = a..

스프링 애플리케이션을 구성할 때 가장 먼저 등장하는 존재가 바로 스프링 컨테이너다. 이 컨테이너는 개발자가 정의한 빈 객체들을 생성하고, 의존관계를 자동으로 주입해주는 중요한 역할을 담당한다. 요구사항 객체 간의 의존관계를 효율적으로 관리하고 싶다.설정 정보를 기반으로 객체를 등록하고, 필요할 때 조회하고 싶다.문제점 매번 객체를 생성하고 의존성을 수동으로 연결하는 건 비효율적이다.프로젝트가 커질수록 객체 관리가 복잡해지고, 결합도가 높아진다.개선 방향: 스프링 컨테이너 도입 스프링에서는 ApplicationContext라는 컨테이너를 통해 객체를 자동으로 생성하고 관리한다. 이를 위해 @Configuration과 @Bean을 활용하여 설정 정보를 기반으로 빈을 등록한다.@Configurationpub..

앞서 AppConfig를 활용해 객체 생성과 의존관계를 분리해보았다.이번에는 이 설정 클래스를 스프링 방식으로 전환해보고,스프링 컨테이너가 어떻게 의존관계를 자동으로 주입해주는지 확인해본다.AppConfig를 스프링 설정으로 전환먼저 @Configuration 과 @Bean 어노테이션을 활용해 AppConfig를 스프링 설정 클래스로 변경한다.@Configurationpublic class AppConfig { @Bean public MemberService memberService() { return new MemberServiceImpl(memberRepository()); } @Bean public OrderService orderService() { ..

이전 포스팅에서는 할인 정책을 교체하기 어려운 구조로 인해 OCP와 DIP를 위반하게 되는 문제를 살펴봤다.이번에는 그 문제를 해결하기 위해 등장한 AppConfig라는 설정 클래스를 중심으로 관심사의 분리와 의존 관계 주입 구조를 적용해보자.객체 생성을 외부로 분리하자서비스 클래스는 자신의 역할(로직 구현)에만 집중하고,필요한 객체의 생성과 연결은 AppConfig가 담당하도록 한다.public class AppConfig { public MemberService memberService() { return new MemberServiceImpl(new MemoryMemberRepository()); } public OrderService orderService() { ..