나의 브을로오그으

스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); - ApplicationContext를 스프링 컨테이너라 한다. - ApplicationContext는 인터페이스다. - 스프링 컨테이너를 XML기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. - 이전 챕터의 AppConfig를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것이다. ※ 참고 : 더 정확하게 스프링 컨테이너를 부를 때 'BeanFactory', 'ApplicationContext'로 구분해서 이야기한다. 일반적으로 컨테이너 생성 시 스프..

지금까지 스프링 프레임워크 없이 순수 자바로만 간단한 애플리케이션을 만들어 보았다!! 이제 간편하고 아주 강력한 스프링 프레임워크의 기능을 이용해 보자. 1. AppConfig 에 @Configuration 애노테이션을 붙여준다. @Configuration public class AppConfig { ... } 2. AppConfig에 @Bean 애노테이션을 붙여준다. package hello.core.order; import hello.core.discount.DiscountPolicy; import hello.core.discount.FixDiscountPolicy; import hello.core.member.MemberService; import hello.core.member.MemberServ..

[IoC, DI 그리고 컨테이너] 제어의 역전 IoC(Inversion of Control) - 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. 한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다. (즉, 프로그램 코드를 작성 할 때, 이 부분에서 객체가 필요할때마다 그때그때 생성해서 사용했다는 의미) - 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다.(SRP) 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. 예를 들어서 OrderServiceImpl은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다. - 프로그램에 대한 제어..

[전체 구조 다이어그램] [AppConfig] (중복을 제거하고, 한눈에 각각의 역할이 보일 수 있도록 분리하자.) package hello.core.order; import hello.core.discount.DiscountPolicy; import hello.core.discount.FixDiscountPolicy; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import hello.core.member.MemoryMemberRepository; public class AppConfig { public MemberService memberService() { return new MemberServ..

[관심사의 분리] - 애플리케이션을 하나의 공연이라 생각해보자. 각각의 인터페이스를 배역(배우 역할)이라 생각하자. 그런데! 실제 배역 맞는 배우를 선택하는 것은 누가 하는가? - 로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할지 줄리엣 역할을 누가 할지는 배우들이 정하는게 아니다. 이전 코드는 마치 로미오 역할(인터페이스)을 하는 레오나르도 디카프리오(구현체, 배우)가 줄리엣 역할(인터페이스)을 하는 여자 주인공(구현체, 배우)을 직접 초빙하는 것과 같다. 디카프리오는 공연도 해야하고 동시에 여자 주인공도 공연에 직접 초빙해야 하는 다양한 책임을 가지고 있다. - 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다. - 디카프리오는 어떤 여자 주인공이 선택되더라도 똑같이 공연을 할 수 있어야..

새로운 할인 정책을 확장 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 청책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문시 1000원을 할인해주고, 20000원 주문시 2000원을 할인해주는 것. [RateDiscountPolicy] package hello.core.discount; import hello.core.member.Grade; import hello.core.member.Member; public class RateDiscountPolicy implements Discou..

[테스트 케이스 만들기] package hello.core.order; import hello.core.member.Grade; import hello.core.member.Member; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; import org.assertj.core.api.Assertions; import org.junit.jupiter.api.Test; public class OrderServiceTest { MemberService memberService = new MemberServiceImpl(); OrderService orderService = new OrderServiceImp..

[주문과 할인 도메인 설계] - 회원은 상품을 주문할 수 있다. - 회원 등급에 따라 할인 정책을 적용할 수 있다. - 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라(변경 가능) - 회사의 기본 할인 정책을 아직 정하지 못했다. 최악의 경우 할인을 정하지 않을 수 있다.(미확정) [Project Tree] [discount/DiscountPolicy] package hello.core.discount; import hello.core.member.Member; public interface DiscountPolicy { /** * @return 할인 대상 금액 */ int discount(Member member, int price); } [discount/FixDisco..

[간단하게 실행해보기] package hello.core; import hello.core.member.Grade; import hello.core.member.Member; import hello.core.member.MemberService; import hello.core.member.MemberServiceImpl; public class MemberApp { public static void main(String[] args) { MemberService memberService = new MemberServiceImpl(); Member member = new Member(1L, "홍길동", Grade.VIP); // 회원가입 memberService.join(member); // 회원조회 M..

비즈니스 요구사항과 설계 회원) - 회원을 가입하고 조회할 수 있다. - 회원은 일반과 VIP 두 가지 등급이 있다. - 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다.(미확정) 주문과 할인 정책) - 회원은 상품을 주문할 수 있다. - 회원 등급에 따라 할인 정책을 적용할 수 있다. - 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.) - 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최약의 경우 할인을 적용하지 않을 수 도 있다.(미확정) 요구사항을 보면 회원 데이터, 할인 정책 같은 부분은 지금 결정하기 어려운 부분이다. 그렇다고 이런 정책이..