0m1n's Develog

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

스프링 컨테이너 아래 코드를 살펴보자. 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(); 결국 인터페이스를 참조하는게 아닌, 직접 객체를 생성을 하게 되는 것이다. 이를 해결하려면 어떻게 해야 할까? 강의에서는 애플리케이션을 하나의 공연으로 비유했다. 각각의 인터페이스는 배역이라고 생각할때, 해당 배역을 맡게 되는 배우를 선택하는 역할은 공연 기획자가 할 것이다...