♪ 학습 내용 싱글톤 방식의 주의점과 @Configuration - CGLIB * 싱글톤 주의 스프링 컨테이너 같은 싱글톤 컨테이너를 이용하든 뭘 하든 싱글토 방식은 무상태로 설계해야한다 클라이언트에(가) 의존적인 필드, 값을 변경할 수 있는 필드 x 가급적 자바에서 공유되지 않는지역변수 파라미터등을 사용 무슨 말이냐? 이해하기 위해서 아래 Test를 해봄 웹 애플리케이션 수많은 요청이 동시에 들어오고, 스프링 컨테이너를 통해 싱글톤 유지되는 것을 저번 학습에서 배웠다 그렇기 때문에 여기서 statefulService1 과 statefulService2는 같은 객체 인스턴스를 참조한다. A사용자가 10000원을 주문하고 getPrice()를 통해 주문 금액을 반환 받으려고 하는데 그 사이에 B사용자가 2..

♪ 학습 내용 싱글톤 패턴 및 싱글톤 컨테이너 * 싱글톤 웹 애플리케이션은 특성상 여러 고객이 동시에 요청을 한다 만약 DI컨테이너인 AppConfig에서 여러 고객이 동시에 요청을 한다면 각 요청마다 새로운 객체 인스턴스를 생성해버린다 매우 낭비..!! 싱글톤 패턴 : 객체가 딱 1개만 생성되고 공유하도록 설계 - static 영역에 객체를 1개 미리 생성해둔다 - 그 객체는 getInstance()메서드를 통해서만 접근 가능 - private으로 생성자 제한. 외부에서 new 연산자로 객체를 생성하지 못한다 즉, 여러 호출이 들어와도 같은 객체 인스턴스를 반환. 싱글톤 패턴. 싱글톤 문제점 - 코드가 늘어남 - 구현에 의존 ( 클라이언트에서 구체클래스.getInstance를 사용하게 되는) DIP위반..

♪ 학습 내용 XML 기반 스프링 컨테이너 생성 빈 설정 메타 정보 BeanDefinition * 스프링 설정 형식 스프링 컨테이너는 설정 정보를 다양한 형식으로 받아들일 수 있다. ApplicationContext(스프링 컨테이너) 아래에 이를 구현하는 다양한 형식의 설정 정보 XxxApplicationContext는 Xxx을 설정 정보로 사용하는 ApplicationContext이다 ex) GenericXml ApplicationContext는 GenericXml, 구체적으로는 appConfig.xml을 설정 정보로 사용하는 ac * XML기반 설정 사용해왔던 AppConfig.java 와 구조만 다르지, 거의 똑같다 xml 기반은 스프링 부트를 사용하면서 잘 사용하지 않는 추세 따라서 이렇게 스프링..

♪ 학습 내용 동일 타입과 상속 관계에 따른 스프링 빈 조회 BeanFactory , Application Context * 동일 타입 빈 조회 둘 이상의 동일 타입 스프링 빈이 있을 때 타입으로 조회 시 오류 발생 해결하기 위해 빈 이름을 지정한다 (너무도 당연한 얘기일지도..) 빈 이름은 따로 지정하지 않는 한 @Bean 메서드의 이름이다. * 상속 관계의 스프링 빈 조회 부모 타입을 조회 --> 자식 타입도 조회 static import를 사용하여 앞에 Assertions 생략 assertThrowos( 예외, 로직); == 로직을 실행했을 때 해당 하는 예외가 터질 경우 통과이다 위 사진에서 통과 했다는 것은 DiscountPolicy를 타입으로 조회하였을 때 둘 이상의 스프링 빈이 조회됐다는 것..

♪ 학습 내용 스프링 컨테이너의 생성과정과 빈 조회 * 스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext : 스프링 컨테이너이자 인터페이스 즉, new 이하의 클래스는 ApplicationContext 인터페이스의 구현체. 과정 1. 스프링 컨테이너 생성 구성 정보를 지정하여 컨테이너 생성한다 (코드에서는 AppConfig.class를 파라미터로 넘겨줌으로써 지정함) 2. 스프링 빈 등록 @Configuration과 파라미터로 넘김으로써 구성 정보로 지정한 클래스의 @Bean 전부 호출 호출 후 반환되는 객체를 스프링 빈 저장소..

♪ 학습 내용 IoC / DI / 컨테이너 / 스프링으로의 전환 * 제어의 역전 IoC ( Inversion of Control ) 기존에는 클라이언트가 스스로 필요한 구현객체를 생성하고 연결하고 실행. 즉, 구현 객체가 프로그램 제어 흐름을 조종 이제는 AppConfig가 등장하면서 제어의 흐름을 가져갔다. 클라이언트 객체는 열심히 실행만 할 뿐이다. 이처럼 제어 흐름을 직접 제어하는 것이 아닌, 외부에서 관리하는 것을 제어의 역전. IoC라고 한다 * 의존관계 주입 DI ( Dependency Injection ) - 정적인 클래스 의존 관계 클래스가 사용하는 코드만 보고도 의존관계를 쉽게 파악 가능 실행 없이 분석 가능. 단, 실제 어떤 구현 객체가 주입될 지는 알 수 없다 - 동적인 객체 의존 관..

♪ 학습 내용 AppConfig 리팩터링 / SOLID 적용 * AppConfig 현재 AppConfig를 보면 중복이 존재하고, 역할에 따른 구현이 잘 보이지 않음 리팩터링을 통해 중복을 제거하고 역할에 대한 구현을 한눈에 보기 쉽게 - 기존 new()연산자 중복 제거 ( memberRepository()를 새로 만들음으로써 ) - 메서드 명을 통해 역할이 잘드러난다 - 그 역할에 대한 구현을 한눈에 * 정률할인정책으로 변경 AppConfig를 통해 관심사를 분리하기 이 전에는 구현체를 변경하려면 클라이언트 코드를 직접 변경해야만 했다. (OCP위반) 이제는 AppConfig의 코드만 변경해주면 끝 실제로 위처럼 간단하게 바꿔주고 실행하니 정률할인정책으로 정상 실행되는 것을 확인할 수 있었다. * 좋은..

♪ 학습 내용 AppConfig를 통한 관심사의 분리 * AppConfig 애플리케이션 전체 동작방식을 구성(configuration) / 설정한다. 구현 객체를 생성하고 연결 * 생성자 주입 생성자 주입 == 생성자를 통해 객체를 주입시킨다 이전과는 달리 오로지 인터페이스에 대한 내용만 있음. 즉, 추상화에만 의존하였고 DIP를 지키고 있다. 의존 관계에 대한 고민은 외부(AppConfig)에 맡기고 실행에만 집중 객체를 생성하고 연결하는 역할과 실행하는 역할이 구분되었다. = > 관심사의 분리 * AppConfig 실행 기존에는 MemberServiceImpl을 직접 생성하고 그 MemberServiceImpl이 또 저장소 구현체를 생성했지만, 이제는 AppConfig를 통해 생성하고 주입 받는다 즉..

♪ 학습 내용 개발한 코드에서 구현체 변경(고정할인 → 정률 할인) 즉, 객체 지향적으로 잘 개발했는지 확인 * 새로운 할인 정책 테스트 정률할인정책으로 변경하기 위해 RateDiscountPolicy를 새로 만들고 테스트 실행 - @DisplayName 애너테이션을 이용하면 테스트를 한글 이름으로 표시할 수 있다. - on demand static import를 이용하면 아래 코드블럭 내에 두번째 코드처럼 더욱 간결히 가능 Assertions.asserThat(discount).isEqualTo(0); assertThat(discount).isEqualTo(0); - 테스트는 실패 확인용 테스트도 꼭 만들어봐야 한다 * 새로운 정책 적용의 문제점 클라이언트인 OrderServiceImpl 할인 정책 구..

♪ 학습 내용 주문 도메인 개발 및 테스트 - 스프링 프레임워크를 왜 사용하는지 알기 위한 과정으로 개발 시에 순수 자바 사용 * 할인 도메인 개발 할인 정책 인터페이스와 정액 할인 정책(FixDiscountPolicy) 구현체 개발 할인 금액을 return 해준다 * 주문 도메인 개발 주문 엔티티 클래스, 주문 서비스 인터페이스, 주문 서비스 구현체 작성 주문 서비스를 구현하기 위해서 회원저장소(등급 조회 목적)와 할인 정책(등급별 할인)이 필요함 [ 11~12라인 ] 할인금액(discountPrice)을 주문 서비스 구현체에서 직접 구하지 않고 할인 정책 구현체에게 넘겼다.[17라인] 단일 체계 원칙 SRP를 잘 고수하여 설계한 것. 전체적 흐름 : 주문 생성 요청 → 회원 정보 조회, 할인 정책 적..