목록인프런 (46)
오늘이라도
강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. 할인 정책 적용과정에서의 문제점 - 역할과 구현을 충실하게 분리했다. → OK - 다형성도 활용하고, 인터페이스와 구현 객체를 분리했다. → OK - OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했다. → 그렇게 보이지만 사실은 아니다. - DIP : 주문서비스 클라이언트(OrderServiceImpl)는 DiscountPolicy 인터페이스에 의존하면서 DIP를 지킨 것 같지만 → 클래스 의존관계를 분석해 보면, 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다. - 추상(인터페이스) 의존 : DiscountPolicy - 구체(구현) 클래스 : FixDiscountPolicy, RateDiscountPolic..
강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. 새로운 할인 정책을 확장해보자 - 객체지향 설계 원칙을 잘 준수 했는지 확인해보자. - 주문한 금액의 %를 할인해주는 새로운 정률 할인 정책을 추가하자. 2. RateDiscountPolicy 추가 3. RateDiscountPolicy 작성 4. 테스트 코드 작성 - Ctrl + Shift + t : Create Test - Assertions에 Alt + Enter -> Add on-demand static import for 'org.assertj.core.api.Assertions' 로 스태틱 import 활용
강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. OrderApp 클래스 작성 및 실행 2. OrderServiceTest 클래스 작성 후 테스트
강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. 인터페이스 및 클래스 작성 - discount 패키지 및 order 패키지의 인터페이스와 클래스 작성
강의 링크 ※ 코드는 저작권 상 올릴 수 없다고 합니다 ㅜㅜ 1. 주문과 할인 정책 - 회원은 상품을 주문할 수 있다. - 회원 등급에 따라 할인 정책을 적용할 수 있다. - 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경될 수 있다.) - 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) 2. 주문 도메인 협력, 역할, 책임 ① 주문 생성 : 클라이언트는 주문 서비스에 주문 생성을 요청한다. ② 회원 조회 : 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회한다. ③ 할인 적용 : 주문 서비스는..
강의 링크 ※ 코드는 저작권 상 올릴수 없다고 합니다 ㅜㅜ 1. MemberApp 작성 - MemberApp에서 임의로 join 후 findMember로 비교해본 결과 2. MemberServiceTest 작성 - jUnit을 활용해 given - when - then 형식으로 테스트클래스 작성 후 실행해본 결과 3. 회원 도메인 설계의 문제점 - 다른 저장소로 변경할 때 OCP 원칙을 잘 준수할까? - DIP를 잘 지키고 있을까? - 의존관계가 인터페이스 뿐만 아니라 구현까지 모두 의존하는 문제점이 있음 → 주문까지 만들고나서 문제점과 해결 방안을 설명