빛나는 아이디어✨

9.1 빈 스코프 지금까지는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때 까지 유지된다고 배웠다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 빈이 존재할 수 있는 범위를 뜻한다. 스프링 빈이 지원하는 스코프 1) 싱글톤 기본 스코프로 스프링 컨테이너의 시작부터 종료까지 유지되는 가장 넓은 범위의 스코프이다. (생명주기 == 스프링 컨테이너) 2) 프로토타입 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다. 3) 웹 관련 스코프 - request : 웹 요청이 들어오고 나갈때까지 유지되는 스코프이다. - session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스..

8.1 빈 생명주기 콜백 시작 애플리케이션은 시작 시점에 필요한 연결을 미리 해두고, 종료 시점에 연결을 안전하게 종료하려면, 객체의 초기화와 종료 작업이 필요하다. 1) 데이터베이스 커넥션 풀 웹 어플리케이션과 데이터베이스는 서로 다른 시스템이므로, 데이터베이스 드라이버를 통해 데이터베이스에 연결 사용자로부터 요청이 올때마다 TCP 소켓을 열고 닫는 것은 시간이 오래 걸림 어플리케이션 서버와 DB를 미리 연결해 놓고, 필요할 때 재활용하여 사용 2) 네트워크 소켓 소켓을 미리 연결해 놓고, 사용자 요청이 들어오면 열러 있는 소켓을 이용하여 빠른 연결 가능 스프링을 통한 초기화와 종료 작업 예제는 다음과 같다. 서버가 뜨기 전에 외부 네트워크에 미리 연결을 해 놓고, 서버 종료 전에 미리 연결을 끊어야 ..

3.9.1 스프링으로 전환하기 - AppConfig 클래스 지금까지는 순수한 Java 코드로 DI 를 적용하였다. 이를 스프링으로 전환시켜보자. 먼저, AppConfig 클래스를 다음과 같이 작성한다. package hello.core; import hello.core.discount.DiscountPolicy; import hello.core.discount.RateDiscountPolicy; import hello.core.member.MemberRepository; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import hello.core.member.MemoryMemberRepository;..

3.8.1 IoC (Inversion of Control) 란? 기존의 코드에서는 클라이언트 구현 객체가 필요한 서버 구현 객체를 생성, 연결, 실행하였다. 하지만, 프로그램의 제어 흐름을 결정하는 AppConfig 를 사용하여, 구현 객체는 자신의 로직만 실행하도록 변경하였다. 따라서, OrderServiceImpl 클래스의 경우 필요한 인터페이스를 호출하여도, 어떤 구현 객체가 실행될지는 알지 못한다. 여기서, 프로그램에 대한 제어 흐름 권한을 AppConfig 가 가지고 있는 것을 볼 수 있다. AppConfig 는 OrderServiceImpl 또는 다른 객체를 생성하고 실행하지만, OrderServiceImpl 은 이를 알지 못한 채, 자신의 로직만을 수행한다. 즉, 프로그램의 제어 흐름을 직접..

3.7.1 SRP 단일 책임 원칙 좋은 객체 지향의 5가지 설계 원칙이 어떻게 적용되었는지 하나씩 살펴보자. SRP : 하나의 클래스는 하나의 책임만 가져야 한다. 기존의 OrderServiceImpl 객체의 경우 다양한 책임을 가짐 : 구현 객체 생성, 연결, 실행 등을 담당하였다. 관심사를 분리하여 SRP 단일 책임 원칙을 적용 : AppConfig가 구현 객체를 생성하고 연결하는 책임을 담당한다. : 클라이언트 객체는 실행하는 책임만 담당한다. 3.7.2 DIP 의존관계 역전 원칙 DIP : " 추상화에 의존해야 하고, 구체화에 의존하면 안된다" 의 원칙을 따르는 방법 중 하나 기존의 OrderServiceImpl 객체의 경우 추상화와 구체화 모두 의존 : DiscountPolicy 추상화 인터페이..

3.5.1 정률 할인 정책 적용 다시 처음으로 돌아가서, 정액 할인 정책(FixDiscountPolicy)을 정률 할인 정책(RateDiscountPolicy)으로 변경해보자. 어플리케이션의 전체 설정을 결정하는 AppConfig 가 등장하면서, 어플리케이션은 사용 영역과 구성영역으로 분리되었다. 따라서, FixDiscountPolicy 를 RateDiscountPolicy 로 변경하여도, 구성 영역만 변경되고, 사용 영역은 영향을 받지 않는다. 즉, AppConfig 만 수정하면, 클라이언트 변경 없이 할인 정책을 수정할 수 있다. 3.5.2 AppConfig 수정 정률 할인 정책을 적용하기 위해, AppConfig 클래스를 다음과 같이 수정한다. package hello.core; import hel..

3.4.1 AppConfig 코드 문제점 앞서 섹션 3.3 에서 작성한 AppConfig 에는 중복이 있고, 역할에 따른 구현이 잘 보이지 않는다. 아래의 다이어그램을 살펴보자. 클라이언트가 주문을 할 때, 주문 서비스 역할에 의존하고, 주문 서비스 역할은 회원 저장소와 할인 정책 역할에 의존한다. 어플리케이션 설정 정보인 AppConfig 에서는 이러한 정보를 한 눈에 볼 수 있어야 하는데, 현재 코드에는 이러한 역할들이 제대로 드러나지 않는 문제점이 있다. 현재 AppConfig 코드 package hello.core; import hello.core.discount.FixDiscountPolicy; import hello.core.member.MemberService; import hello.cor..

3.3.1 관심사의 분리 어플리케이션을 공연, 인터페이스를 배우, 남자 주인공, 여자주인공을 구현체라고 가정해보자. 로미오와 줄리엣 공연을 한다고 가정하면, 남자 주인공(구현체) 를 결정하는 것은 기획자의 역할이다. 하지만, 이전 코드는 여자 주인공(구현체) 를 남자 주인공(구현체) 가 직접 초빙하는 것과 같다. 즉, 남자 주인공 (구현체) 는 공연을 하고, 여자 주인공을 초빙해야 하는 다양한 책임을 갖게 된다. 이러한 문제는, 다음과 같은 관심사의 분리를 통해 해결할 수 있다. 관심사의 분리 1) 배우는 배역을 수행하는 것에만 집중해야 한다. (한가지 책임) 2) 공연을 구성하고 기획하는 별도의 공연 기획자가 필요하다. 3) 공연 기획자를 만들고, 배우와 공연 기획자의 관심사를 분리하여야 한다. 3.3..

3.2.1 새로운 할인 정책 적용 앞서 섹션 3.1 에서 작성한 RateDiscountPolicy 를 적용시켜보자. 새로운 할인 정책을 적용시키기 위해서는, OrderServiceImpl 클래스를 다음과 같이 변경해야 한다. public class OrderServiceImpl implements OrderService { // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); } 주석 처리한 FixDiscountPolicy 대신 RateDiscountPolicy 로 변경하였다. 여기서, 한 가지 문제..

3.1.1 새로운 할인 정책 앞서 섹션 2에서 작성한 코드에 좋은 객체 지향의 원리들을 적용해보자. 먼저, 새로운 기획자가 나타나서 다음과 같은 정책을 추가해달라고 요구한다고 가정하였다. 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문시 1000원을 할인해주고, 20000원 주문시에 2000원을 할인해주는 거에요! 즉, 할인 정책을 고정 할인 금액에서 정률 할인으로 변경해야 하는 것이다. 하지만, 앞선 코드에서 유연한 설계가 가능하도록 객..