♪ 학습 내용 스프링 컨테이너의 생성과정과 빈 조회 * 스프링 컨테이너 생성 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를 잘 고수하여 설계한 것. 전체적 흐름 : 주문 생성 요청 → 회원 정보 조회, 할인 정책 적..

* NullPointerException 자바 프로그램에서 가장 빈번하게 발생하는 실행 예외 null 값을 갖는 참조 변수로 객체 접근 연산자인 " . " 를 사용했을 때 발생한다. 즉, 객체가 없는 상태에서 객체를 사용하려 해서 발생하는 예외인 것이다. public class NullPointerExceptionExample{ public static void main(String[] args){ String data = null; System.out.println(data.toString()); } } data 변수는 null 값을 가지기 때문에 String 객체를 참조하지 않는데 String객체의 toString()을 호출하고 있다. NullPointerException 발생 * 에러 이처럼 jav..

♪ 학습 내용 회원 도메인 테스트 / 주문 할인 도메인 설계 - 스프링 프레임워크를 왜 사용하는지 알기 위한 과정으로 개발 시에 순수 자바 사용 * 회원도메인 테스트 실제 서버 띄워 실행 시 객체들 간 참조 관계는 다음과 같다 - 1L 의 L은 id의 자료형인 Long을 의미한다. 이와 같은 테스트 방식은 직접 결과 호출해 눈으로 확인하여 검증해야 하는 단점이 있다. * 회원도메인 테스트( JUnit 테스트 ) 기존 main 패키지가 아닌 test를 이용한다 다음 구조로 나누어 test 코드 작성하면 조금 더 알아보기 쉽다 // given 이런 이런게 주어졌을 때 // when 이렇게 했을 때 //then 이렇게 된다. 검증. 결과를 호출해 눈으로 검증했던 조금 전 방식과는 다르게 편하게 결과 확인이 가..

♪ 학습 내용 회원 도메인 / 저장소 / 서비스 개발 - 스프링 프레임워크를 왜 사용하는지 알기 위한 과정으로 개발 시에 순수 자바 사용 * 회원 도메인 개발 회원 등급 클래스와 회원 엔티티 클래스를 작성했다. 엔티티 클래스인 Member 클래스는 필드 id, name, grade . 생성자와 각 필드 Getter Setter를 가지고 있다. * 회원 저장소 개발 회원 저장소 인터페이스 MemberRepository 와 실제 구현체인 MemoryMemberRepository를 구현 회원을 저장하는 save() 와 id를 조회하는 findById() . 이 두가지 메서드를 가지고 있다. 실제 저장소 구현체인 MemoryMemberRepository에서는 데이터를 저장할 HashMap 따라서 save() 와..

♪ 학습 내용 스프링 프로젝트 생성 및 예제 설계 - 스프링 프레임워크를 왜 사용하는지 알기 위한 과정으로 개발 시에 순수 자바 사용 * 프로젝트 생성 및 실행 https://start.spring.io 이용 아직은 스프링 프레임워크를 사용하지 않을 것이기에 DEpendencies 별도의 의존 관계 설정 x 압축 풀어주고 IntelliJ에서 build.gradel로 열어주었다. * 비즈니스 요구사항 / 설계 회원 - 가입, 조회 기능 - 일반 / VIP 등급 - 회원 데이터는 어떤 것으로 구현할지 미정 ( = 역할과 구현을 구분하여 인터페이스를 만들고 구현체 갈아끼우자 ) 주문 , 할인 - 회원은 상품 주문 - 등급에 따라 할인 정책 - 모든 VIP 고정 1000원 할인 (변경 가능) - 할인 정책 변경..