0m1n's Develog

스프링에서 조회 대상 빈이 2개 이상일 때 해결할 수 있는 방법을 알아보자. @Autowired 필드명 @Qailifier → @Qailifier끼리 매칭 → 빈 이름 매칭 @Primary 사용 1. @Autowired 필드 명 매칭 @Autowired 는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭 타입 매칭 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭 기존 코드 @Autowired private DiscountPolicy discountPolicy; 필드 명을 빈 이름으로 변경 @Autowired private DiscountPolicy rateDiscountPolicy; 2. @Qualifier 사용 @Qualif..

의존관계 주입은 크게 4가지 방법이 있다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 1. 생성자 주입 지금까지 진행했던 방법 생성자 호출시점에 딱 1번만 호출되는 것이 보장 '불변, 필수' 의존관계에 사용 OrderServiceImpl을 확인해보자. @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) { this.memberRepository = memberRepository; this.discountPolicy = discountPolicy; } 생성자를 통해서만 DI가 되며, 누구도 외부에서 수정할 수 없다. 생성자가 딱 1개만 있으면 @Au..

컴포넌트 스캔에서 같은 빈 이름을 등록하게 되는 경우 충돌이 발생할까? 아래와 같이 2가지 상황이 있다고 하자. 자동 빈 등록 vs 자동 빈 등록 수동 빈 등록 vs 자동 빈 등록 1. 자동 빈 등록 vs 자동 빈 등록 역시 충돌이 나며, 에러를 발생시킨다. 2. 수동 빈 등록 vs 자동 빈 등록 헷갈릴 수 있는 부분이다. 테스트를 해보자! AutoAppConfig 파일에 아래와 같이 다른 빈을 등록한다. public class AutoAppConfig { @Bean(name = "memoryMemberRepository") MemberRepository memberRepository(){ return new MemoryMemberRepository(); } } MemoryMemberRepository ..

스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. (스프링 컨테이너 생성과정에서, 컨테이너는 객체를 하나만 생성해서 관리) 스프링 컨테이너가 싱글톤 컨테이너 역할을 해서 싱글톤 객체를 생성하고 관리한다. 이 기능을 싱글톤 레지스트 라고 한다. 싱글톤 레지스트의 장점은 싱글톤 패턴을 위한 지저분한 코드 필요x DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤 사용 가능 이전의 코드에서 스프링 컨테이너를 사용하는 부분만 바꾸어 테스트를 진행해보자! void springContainer(){ // AppConfig appConfig = new AppConfig(); ApplicationContext ac = new AnnotationConfigAppli..

대부분의 스프링 애플리케이션은 웹 애플리케이션이다. (물론 애플리케이션 개발도 가능) 웹 애플리케이션의 경우 보통 여러 고객이 동시에 요청을 하게 된다! 따라서 요청이 올때마다 객체를 만들게 되는 경우가 발생한다. (아래 AppConfig 에서도 memberService 요청이 들어오면 그 객체를 만들어준다.) @Configuration // 설정 정보 public class AppConfig { @Bean // 클래스 스프링 컨테이너에 등록 public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); // memberService 구현체, 객체 생성 } } 테스트를 진행해보자. AppConfig 파일에서 가..

스프링은 BeanDefinition 으로 메타 정보를 추상화 한다. 스프링의 BeanDefinition 추상화를 쉽게 생각해보면, 역할과 구현을 개념적으로 나눈 것이라 할 수 있다. (스프링 컨테이너는 XML, 자바 코드에 관계 없이 BeanDefinition만 알면 된다.) BeanDefinition : 빈 설정 메타 정보 - @Bean, 당 각각 하나씩 메타 정보가 생성됨 - 스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈 생성 BeanDefinition을 직접 생성해서 스프링 컨테이너에 등록할 수 도 있다. (실무에서는 거의 없다!) 스프링 빈을 만드는 2가지 방법이 있는데, 직접 등록하는 방법 factoryBean을 사용하여 등록하는 방법 (일반적인 자바 코드를 통해 등록하는 방법 이 있다.

스프링 컨테이너 아래 코드를 살펴보자. ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); // AnnotationConfigApplicationContext는 ApplicationContext 인터페이스의 구현체 위 코드에서 ApplicationContext 를 스프링 컨테이너라고 한다. (ApplicationContext는 인터페이스) 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 위 방식처럼 애노테이션 기반 자바 설정 클래스로 만들 수 있다. 기존의 Appconfig를 사용해서 직접 객체를 생성하고 DI → 스프링 컨테이너를 통해 사용 스프링 컨테이너는 @Configurat..

제어의 역전 IoC(Inversion of Control) 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것 기존 프로그램에서는 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성/연결/실행했다. (이전 예시 코드를 통해 확인할 수 있다.) private final MemberRepository memberRepository = new MemoryMemberRepository(); 그러나 의존성 주입(DI)을 통해 AppConfig에서 프로그램을 제어하고, 구현 객체는 자신의 로직을 실행하는 역할만 담당하게 됐다. public class MemberServiceImpl implements MemberService { // private final MemberRepositor..

애플리케이션을 개발하던 중, DIP에 위반할 수 밖에 없는 상황이 왔다. DIP - 의존 관계를 맺을 때 변화하기 어려운 것, 거의 변화가 없는 것에 의존 - 구현 클래스에 의존하지 말고 인터페이스에 의존해야 한다. - 역할에 의존하게 해야 한다. (역할과 구현을 철저하게 분리하도록!!) 아래 코드를 보자. private final DiscountPolicy discountPolicy = new FixDiscountpolicy(); 결국 인터페이스를 참조하는게 아닌, 직접 객체를 생성을 하게 되는 것이다. 이를 해결하려면 어떻게 해야 할까? 강의에서는 애플리케이션을 하나의 공연으로 비유했다. 각각의 인터페이스는 배역이라고 생각할때, 해당 배역을 맡게 되는 배우를 선택하는 역할은 공연 기획자가 할 것이다...

- SOLID 5원칙 1. SRP (Single responsibility principle) : 단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다. 하나의 책임이라는 것은 모호하다. (클 수도 있고, 작을 수도 있다.) 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 SRP를 잘 따른 것이다. -> 특정 목적의 클래스는 그 목적 외에 다른 기능을 가지면 안된다는 뜻! 2. ★ OCP (Open/closed principle) : 개방-폐쇄 원칙 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현 다형성(오버라이딩, 오버로딩 등)을 활용해보자 다형성 (Polymorphism) : 하나의 객체가 여러 가..