개발자되기 프로젝트

현채 AppConfig는 중복이 있고, 역할에 따른 구현이 잘 안보인다. public class AppConfig { public MemberService memberService(){ return new MemberServiceImpl(new MemoryMemberRepository()); } public OrderService orderService(){ return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy()); } } 아래와 같이 역할과 구현이 분명히 보이도록 수정해 주자. MemberRepository가 어떤 구현체를 사용할지 분명하게 보임 --> 변경 용이 DiscountPolicy가 어떤 구현체를 사용할..

애플리케이션은 하나의 공연 인터페이스 = 역할(배역) 그럼 배우 선택은 누가?? 배우선택은 배우가 하지 않는다. 클라이언트가 인터페이스와 구현체 모두 의존했다. 인터페이스 = new 구현체() 즉, 다른 배우(클라이언트)가 다른 배역의 배우를 선택한 것과 같다. 이상하지않음? 배우는 다른 배우가 정할 수 없고 기획자나 감독이 지정해야한다. 이전 코드를 다시 보면 배우의 역할에 배우 선택까지 포함이 되었던 것이다. 관심사 분리가 되지 않았던 것이다. 따라서 기획자를 만들어 배우, 감독의 책임을 화아아악실히 분리해야 한다. 즉! 어떤 구현체를 사용할지 정하는 것은 클리이언트에서 하지 않는다! 1. 그럼 누가 구현체를 정하는데? AppConfig 애플리케이션의 전체 동작 방식을 구성(config)하기 위해 "..

https://github.com/bsh6463/SpringCoreFunction1. 정책 변경 할인 정책을 바꾸기 위해서는 DiscountPolicy의 구현체를 바꿔줘야 한다. OrderServiceImpl은 현재 FixDiscountPolicy를 의존하고 있다. FixDiscountPolicy를 RateDiscountPolicy로 변경 하지만 할인 정책을 바꾸기 위해서는 클라이언트인 OrderServiceImpl의 코드를 변경해야 한다. OCP, DIP를 위반한다! - DIP : DiscountPolicy 인터페이스 뿐 만 아니라 구체적은 클래스도 의존하고 있다. - OCP : 변경에 닫혀있지 않다. 기능을 확장하기 위해서 클라이언트 코드 변경이 필요하다. 즉, FixDiscountPolicy -->..

??? : 할인정책 10%할인으로 바꿔!! 1. RateDiscountPolicy class DiscountPolicy interface의 구현체 member와 price정보를 받아 할인 금액 return public class RateDiscountPolicy implements DiscountPolicy{ private int discountPercent = 10; @Override public int discount(Member member, int price) { if(member.getGrade() == Grade.VIP){ return price * discountPercent / 100; }else { return 0; } } }​ 2. 할인금액 Test @DisplayName을 입력하면 t..

1. DiscountPolicy Interface DiscountPolicy의 역할 : Member, 가격을 받아 할인 금액을 return 추후 변경이 용이하게 interface생성 후 구현체 생성. public interface DiscountPolicy { /** * @return 할인 대상 금액 */ int discount(Member member, int price); } 2. FixDiscountPolicy Class DiscountPolicy의 구현체 Override하여 method 구현 member, price를 받아 member 등급에 해당하는 할인금액 return. public class FixDiscountPolicy implements DiscountPolicy{ private int..

1. 주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있 다.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) 2. 주문 도메인 협력, 역할, 책임 주문 생성 : 클라이언트는 주문 서비스에 주문 생성을 요청 회원조회 : 할인을 위해서는 회원 등급이 필요. 주문 서비스는 회원 저장소에서 회원 조회 할인 적용 : 주문 서비스는 회원 등급에 다른 할인 여부를 할인 정책에 위임! 주문 결과 반환 : 주문 서비스는 할인 결과를 포함한 주..

요구사항 및 클래스 다이어 그램은 이전 글 참고 비즈니스 요구사항 & 설계 스프링 부트는 환경설정을 위해서만 사용. 스프링 없이 순수 자바로만 진행! 회원 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 bsh-developer.tistory.com 1. Member class public class Member { private Long id; private String name; private Grade grade; public Member(Long id, String name, Grade grade) { this.id = id; this.name = name; this.grade = grade; } public Long getId(..

스프링 부트는 환경설정을 위해서만 사용. 스프링 없이 순수 자바로만 진행! 회원 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정) 주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있 다.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) 미확정된 사항이 있다. 따라서 인터페이스를 만들고 구현체를 갈아낄 수 있도록 설..