개발자되기 프로젝트

1. 제어의 역전(Inversion of Control) 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성, 연결, 실행함 즉, 구현객체가 프로그램의 제어 흐름을 스스로 조종. 주우우욱 작성하다가 필요한거 있으면 호출해서 쓰고.. 자연스러움 근데 AppConfig이후 구현 객체는 온전히 자신의 로직을 실행하는 역할만 가짐. 프로그램의 제어 흐름에 대한 권한은 AppConfig가 가져감. 프로그램의 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라 함. 2. 프레임워크 vs 라이브러리 프레임워크가 내가 작성한 코드를 제어, 대신 실행함. 내가 제어의 흐름을 담당하면? 그건 라이브러리임. 3. 의존관계 주입(DI) 의존관계는 "정적인 클래스 의존 관계"와 "..

이전에 할인 정책을 바꾸려다보니 DIP, OCP위반이 발생하여 AppConfig를 도입하여 관심대상을 분리하였다. 1. 사용, 구성의 분리 할인 정책은 변경하기 위해서는 구성 영역의 코드만 변경해 주면 된다. 변경 전 변경 후 2. AppConfig 수정 public class AppConfig { public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } public OrderService orderService(){ return new OrderServiceImpl(memberRepository(), discountPolicy()); } private MemoryMemberRepository memb..

현채 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. 주문 도메인 협력, 역할, 책임 주문 생성 : 클라이언트는 주문 서비스에 주문 생성을 요청 회원조회 : 할인을 위해서는 회원 등급이 필요. 주문 서비스는 회원 저장소에서 회원 조회 할인 적용 : 주문 서비스는 회원 등급에 다른 할인 여부를 할인 정책에 위임! 주문 결과 반환 : 주문 서비스는 할인 결과를 포함한 주..