developer h1 developer h1

새로운 할인 정책을 사용하려면 아래와 같이 필수적으로 OrderService의 수정이 일어난다 - 우리는 역할과 구현을 충실하게 분리했다 - 다형성도 활용하고, 인터페이스와 구현 객체도 분리했다 - OCP, DIP 같은 객체지향 설계 원칙을 충실하게 준수했다 - 그렇게 보이지만 사실은 아니다 - 클래스 의존관계를 분석해 보자. 추상(인터페이스) 뿐만 아니라 구체(구현)클래스에도 의존하고 있다 - 추상 의존 : DiscountPolicy - 구체 클래스 : FixDiscountPolicy, RateDiscountPolicy - DIP 위반 - OCP : 기능을 확장해서 변경하려면 지금처럼 클라이언트 코드에 영향을준다 - OCP 위반 어떻게 이 문제를 해결할 수 있을까? DIP 위반 -> 추상에만 의존하도록..

기존의 코드에 객체지향의 원리를 적용해 보자 기획자가 나타나 새로운 할인 정책을 추가해달라고 요구해왔다고 가정한다 이전까지 OCP, DIP 를 못지켰던 문제가 직접적으로 드러나고, 이것을 해결하기 위해 여러 시도를 하다보면 자연스레 스프링의 핵심 기능인 스프링 컨테이너가 왜 탄생했는지 이해할 수 있다 마지막엔 이 순수한 자바코드를 스프링 컨테이너에서 동작하도록 간단하게 바꿔 볼 것이다 바꿀 할인 정책의 내용은 이렇다 10000원 이라면 1000원 할인, 20000 은 2000, 30000만은 3000으로 할인해 주는 정률 할인으로 변경하자 중간에 @DisplayName 의 내용이 콘솔에서 깨져 나오는 현상이 나타났고, 검색으로 쉽게 해결할 수 있는 문제였다

main메소드 테스트 테스트 성공 이제 jUnit 으로 옮겨 보자 성공 아직 어색함을 많이 느껴서 정리 한번 하고 간다 멤버 아이디 선언 멤버 객체 선언 멤버 서비스의 join 실행 오더 서비스의 createOrder실행 (memberId사용) 결과 확인은 Assertions.assertThat 으로... 다음은 실제로 요구사항이 변경됐을 때를 가정하여 구현체를 변경했을 때, 아무런 문제 없이 실행이 가능한가를 실제로 확인해 보자

OrderService는 할인 정책이 어떤지 전혀 알지 못하고 있으며, 주문을 하는 본인의 역할에만 집중하고 있다 이것이 단일 책임 원칙, SRP 를 잘 준수하고 있는 모습이다 할인 정책이 변경 되어도 OrderService는 전혀 수정할 필요가 없다

-다이어그램 설명- ->클라이언트는 주문 생성 기능을 사용할 수 있다 - 회원id - 상품명 - 상품 가격 -> 주문 서비스 역할 : 회원 조회, 할인 적용을 하기 위해 각각의 인터페이스들을 사용하고, 클라이언트에게 결과 반환 -> 회원 저장소 역할, 할인 정책 역할 예제를 간단하게 하기 위해서 상품 데이터들이 아닌, 상품명, 상품 가격만 만들었다 같은 이유로 주문 데이터를 DB에 저장하는 과정도 생략하고, 클라이언트에게 보내는 것 까지만 구현 한다 회원 저장소와 동일하게, 할인 정책 또한 구현체를 갈아끼울 수 있다 처음 설명했던대로, 아직 정해지지 않은 할인 정책을 임의로 사용하다가 교체할 수 있다 슬슬 다이어그램을 글로 설명하는데 한계를 느끼기 시작했다... 앞으로 관련된 내용은 좀 생략하고 개념과 ..

원래는 역할에 맞게 패키지를 구분해 주는게 맞지만, 강의가 복잡해지지 않도록 member 패키지에 전부 몰아 넣는다 HashMap 같은 경우는 동시성 오류가 생길 수 있다 때문에 실제 개발에선 ConcurrentHashMap 를 사용하는데, 이번엔 학습 용도로 개발하는 것이 목적이니 HashMap을 사용했다 다음은 잘 작동하는지 실행과 테스트를 진행하자

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

스프링과 객체 지향의 관계 - 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원한다 - DI(Dependency Injection) : 의존관계, 의존성 주입 - DI 컨테이너 제공 - 클라이언트 코드의 변경 없이 기능 확장 - 쉽게 부품을 교체하듯이 개발 정리 - 모든 설계에 역할과 구현을 분리하자 - 자동차, 공연의 예를 떠올려보자 - 애플리케이션 설계도 공연을 설계 하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계다 - 이상적으로는 모든 설계에 인터페이스를 부여하자 실무 고민 - 하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다 - 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 ..