발자국남기기

BeanFactory❓❓ ApplicationContext❓❓ BeanFactory 스프링 컨테이너의 최상위 인터페이스 스프링 빈을 관리하고 조회하는 역할 담당 getBean()을 제공 앞서 Bean을 조회하고 꺼내는 등의 대부분 기능은 BeanFactory가 제공하는 기능 ApplicationContext BeanFactory기능을 모두 상속받아 제공한다. 빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데 그럼 둘의 차이는 무엇일까? 애플리케이션을 개발할 때 빈은 관리 / 조회 기능과 더불어 수 많은 부가 기능이 필요 그 부가 기능을 제공 실제로 ApplicationContext에 들어가보면 여러가지를 상속받고 있고 최상위에 BeanFactory가 있음을 확인할 수 있다. 🙀Applic..

기본 스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법 ac.getBean(빈이름, 타입) ac.getBean(타입) 조회 대상 스프링 빈이 없으면 예외 발생 NosuchBeanDefinitionException : No bean named "빈이름" available 1. 빈 이름으로 조회!! Assertions로 검증 memberService가 어떤 객체 인스턴스인지?(isInstanceOf) MemberServiceImpl의 인스턴스라면 테스트 통과 테스트 성공 2. 이름 없이 타입으로만 조회 테스트 성공! 하지만 같은 타입이 여러 개일 경우에는 곤란해질 수 있음. 3. 구체 타입으로 조회 테스트 성공! 스프링 컨테이너에 구현체가 등록만 되어있으면 조회가 됨 스프링 빈에 등록되어 있는 ..

스프링 컨테이너에서 실제 스프링 빈들이 잘 등록 되었는지 확인해보자. Junit 테스트 코드로 작성 1. 모든 빈 출력 Bean명과 담겨있는 객체들을 출력하였다. 위의 org.springFramework ~~ 들은 스프링이 내부적으로 스프링 자체를 확장하기 위해 쓰는 Bean들이다. ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름을 조회 ac.getBean() : 빈 이름으로 빈 객체(인스턴스)를 조회 2. 애플리케이션 빈 출력 getBeanDefinition : Bean에 대한 메타데이터 정보 getRole() : Bean의 역할을 가져오는 메소드 getRole이 ROLE_APPLICATION이라는 뜻은 스프링이 내부적으로 등록한 Bean이 아니라 우리가 Applic..

스프링 컨테이너😙 ApplicationContext 를 스프링 컨테이너라 한다. ApplicationContext 는 인터페이스이다. 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. 직전에 AppConfig 를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것 이다. 자바 설정 클래스를 기반으로 스프링 컨테이너( ApplicationContext )를 만들어보자. new AnnotationConfigApplicationContext(AppConfig.class); 이 클래스는 ApplicationContext 인터페이스의 구현체이다. > 참고: 더 정확히는 스프링 컨테이너를 부를 때 BeanFactory , Appli..

스프링 형식으로 AppConfig 변경 @Configuration : 설정 정보, 애플리케이션의 구성 정보를 담당한다는 뜻의 애노테이션 @Bean : 스프링 빈으로 등록 MemberApp 클래스 ApplicationContext ==> 스프링 컨테이너라고 보면 된다. 앞서 등록한 Bean들을 모두 관리해주는 역할 Parameter로 우리가 만든 AppConfig을 넣어주면 AppConfig의 환경설정 정보를 가지고 객체를 생성하고(@Bean) 스프링 컨테이너에 모두 집어넣은 후 관리해준다. getBean에는 이름과 반환 타입을 적어줘야함. 어떤 Bean을 꺼낼 것인지(메서드 이름) 실행시켜보자! 정상 작동하는 것을 확인할 수 있다. 자세히 살펴보면 appConfig, memberService, membe..

제어의 역전 - IoC (Inversion of Control) 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한 마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다. 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호 출하지만 어떤 구현 객체들이 실행될지 모른다. 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다. 심지어 OrderServiceImpl 도 AppConfig가 생성한다. 그리고 AppCo..

현재 AppConfig에는 중복이 있고, 역할에 따른 구현이 잘 보이지 않는다. MemoryMemberRepository가 중복되어 사용되고 있음. 메소드로 꺼내어 사용 또한 어떤 역할(인터페이스)를 사용하여 구현을 했는지가 보이지 않는다. MemoryMemberRepository는 MemberRepository의 역할을 수행하는데 그것을 확인할 수 없음. 👇 👇 다음과 같이 중복을 제거하고 메소드를 추출하였다 어떤 역할(인터페이스)에서 어떤 구현체를 사용한 것인지 한 눈에 확인할 수 있다. 이는 만약 회원 저장소가 변경될 때 (DB를 사용하거나 jdbc를 연동할 때) memberRepository안의 구현체만 변경해주면 된다. 전체 애플리케이션의 구성이 어떻게 되어있는지 파악가능 정액 할인을 정률 할인..

현재 작성된 코드는 주문서비스 구현체(OrderServiceImpl)가 할인 정책 구현체를 선택하고 있는 상태이다. (FixDiscountPolicy / RateDiscountPolicy) 이를 공연에 대입해보자. 공연은 각 배역이 있고 그에 맞는 배우가 있다. 이를 매칭시켜보면 공연 = 애플리케이션(비지니스 로직 전체) 배역 = 인터페이스 (OrderService, DiscountPolicy) 배우 = 구현체 (OrderService, FixDiscountPolicy / RateDiscountPolicy) 배우가 상대 배역의 배우를 선택하고 있는 것과 똑같은 상황이라 할 수 있다. 즉, 배우가 공연도 해야하고 상대 배역까지 정해야하는 다양한 책임을 가지고 있음. 즉, 우리에게는 공연 기획자같은 역할에 ..

1. 할인 정책 변경 👇 👇 😡😡문제점😡😡 역할과 구현을 충실히 분리했음. 다형성도 활용, 인터페이스와 구현 객체를 분리했음. BUT # DIP 클래스 의존관계를 보면 OrderServiceImpl은 추상(인터페이스)뿐만 아니라 구체(구현)클래스에도 의존하고 있다. 추상 : DiscountPolicy 구체 : FixDiscountPolicy / RateDiscountPolicy 우리가 설계한 의존 관계 실제 의존 관계 클라이언트인 OrderServiceImpl이 인터페이스와 구현체를 함께 의존하고 있다. DIP 위반❌❌❌ # OCP 기능을 확장하여 변경하려고하면, 클라이언트 코드에 영향을 준다. (FixDiscountPolicy를 RateDiscountPolicy로 수정) 할인 정책을 정액할인에서 정률할..

🦹‍♂️요구사항🦹‍♂️ 기존 할인 정책 = 정액 할인 정책(고정 금액) : VIP 무조건 1000원 할인 정률 할인 정책(% 할인)으로 변경하고 싶음 10%할인 10000원 주문시 1000원 할인, 20000원 주문시 2000원 할인 1. 새로운 정책 구현하기 2. 새로운 정책 테스트 새로운 회원객체를 생성하여 할인금액을 return 받아 discount에 저장 Assertions를 사용하여 1000원인지 검증 @DisplayName은 Junit5부터 지원하는 애노테이션으로 테스트 명을 지정해줄 수 있다. 테스트 성공!(오타가 있네..디X 되O) 👯‍♂️테스트를 만들 때에는 성공 테스트 뿐아니라 실패 테스트도 꼭 만들어봐야한다.👯‍♂️ Expected (기대값) = 1000원 Actual (실제값) = ..