스프링기본편25 (스프링 핵심 원리 - 기본편)스프링 빈 조회- 4-(4)동일한 타입이 둘 이상, (5)상속관계, (6) BeanFactory와 ApplicationContext - 스프링 빈 조회- 동일한 타입이 둘 이상 타입으로 조회 시 같은 타입의 스프링 빈이 둘 이상이면 오류가 발생하므로 이 때는 빈 이름을 지정해줘야 함 같은 타입이 둘 이상 있을 때, getBean()을 하면 위와 같은 오류가 발생 - 상속관계 빈을 조회할 때, 상속관계로 되어있다면 ? 부모 타입으로 조회하면 자식 타입도 함께 조회됨 자바 모든 객체의 최고 부모인 Object타입으로 조회하면 모든 스프링 빈을 조회하게 됨. package hello.core.beanfind; import hello.core.AppConfig; import hello.core.discount.DiscountPolicy; import hello.core.discount.FixDiscountPolicy; import hello.. 2023. 4. 2. (스프링 핵심 원리 - 기본편) 4-(1)스프링 컨테이너 생성, (2)컨테이너에 등록된 모든 빈 조회, (3) 스프링 빈 조회-기본 - 스프링 컨테이너 생성 ApplicationContext를 스프링 컨테이너라 함 ApplicationContext는 인터페이스 => 다형성 적용 가능 //스프링 컨테이너 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext를 구현한 것 중의 하나가 AnnotationConfigApplicationContext임. 스프링컨테이너는 XML기반으로도, 에노테이션 기반의 자바 설정 클래스로도 만들 수 있음( 요즘엔 에노테이션 위주) 스프링 컨테이너를 부를 때, 'BeanFactory', 'ApplicationContext'로 구분해서 말함. 다만, 'Bean.. 2023. 4. 1. (스프링 핵심 원리 - 기본편) 3-(7)좋은 객체 지향 설계의 5가지 원칙 적용, (8)IoC, DI, 그리고 컨테이너, (9) 스프링으로 전환하기 - 좋은 객체 지향 설계의 5가지 원칙 적용 어떻게 적용됐는지 알아보자 SRP : 한 클래스는 하나의 책임만 가져야 한다 클라이언트 객체는 기존에 직접 구현 객체를 생성, 연결, 실행하는 책임을 모두 가지고 있었음 SRP 단일 책임 원칙을 따를 수 있도록 관심사를 분리함 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당하도록 함 => 클라이언트 객체는 실행하는 책임만 담당하게 됨. DIP 의존관계 역전 원칙 : 프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나. 새로운 할인 정책을 적용하려면 클라이언트도 함께 변경해야 했음. 기존 클라이언트 코드(OrderServiceImpl)는 DiscountPolicy 추상화 인터페이스에만 의존하는 .. 2023. 4. 1. (스프링 핵심 원리 - 기본편) 3-(4)AppConfig 리택터링, (5)새로운 구조와 할인 정책 적용, (6) 전체 흐름 정리 - AppConfig 리팩터링 지금까지 만들어 놓은 AppConfig 를 살펴보면 중복도 있으며 역할에 따른 구현이 한 눈에 보이지 않는다. 현재 변경 후 이렇게 바꾸면 메서드명을 바꿈으로써 역할이 다 드러남. 나중에 db로 바뀐다면 AppConfig에서 memberRepository 메서드가 리턴하는 객체만 바꿔끼워주면 됨. 역할과 구현이 모두 한 눈에 드러나게 됨 => 애플리케이션 전체 구성이 어떻게 돼 있는지 한번에 파악 가능 - 새로운 구조와 할인 정책 적용 정액할인을 정률할인 정책으로 변경해볼 것. AppConfig만 변경하면 됨! AppConfig로 인해 객체를 생성하고 구성하는 영역과 애플리케이션이 사용되는 영역 이렇게 두 영역으로 크게 분리 됨. 할인 정책 변경하려면 AppConfig 부분.. 2023. 4. 1. (스프링 핵심 원리 - 기본편) 3-(1)새로운 할인정책 개발, (2)새로운 할인 정책 적용과 문제점, (3)관심사의 분리 - 새로운 할인정책 개발 새로운 할인 정책 추가하려면 DIP, OCP를 지키지 못하는 문제 발생 => 이 문제를 해결하기 위해 여러 과정을 거치게 됨. => 새로운 할인 정책 : 기본 1000원 할인에서 10% 할인으로 변경하기 기존에 dicount package에 'RateDiscountPolicy' class를 만들고 기존의 DiscountPolicy Interface 를 implements 하기 class를 작성하고 Ctrl +Shift + T 를 눌러 Test생성하기 Test 작성하기 ( VIP라서 할인이 적용되는 경우와 적용되지 않는 경우 두가지 테스트) - 새로운 할인 정책 적용과 문제 새로운 할인 서비스를 적용하려면 OrderServiceImpl로 들어가야 함. OrderServiceImpl.. 2023. 3. 30. (스프링 핵심 원리 - 기본편) 2-주문과 할인 도메인 (6) 설계 , (7) 개발, (8)실행과 테스트 - 주문과 할인 도메인 설계 주문과 할인 정책을 다시 떠올려보자. 회원 : 상품 주문 가능 회원 등급에 따라 할인 정책 적용 가능 할인 정책 : 모든 vip는 1000원 할인하는 고정 금액 할인 적용(변경 가능) 할인 정책 변경 가능성이 높음 클라이언트는 주문 생성 가능/주문 서비스는 주문 생성의 역할을 함 회원저장소에서 회원 조회 회원등급을 가지고 할인 정책 역할에 할인 적용할 수 있는지 물어보고 그 결과를 주문서비스가 받음(주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임) 주문서비스는 최종적으로 할인까지 적용된 주문결과를 클라이언트에게 반환 위처럼 역할과 구현을 분리 => 자유롭게 구현 객체 조립 가능. 회원저장소와 할인정책 모두 유연하계 변경 가능 정액 할인 정책에서 정률 할인 정책으.. 2023. 3. 27. 이전 1 2 3 4 5 다음
