새로운 할인 정책 개발

정률 할인 정책 개발

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;

public class RateDiscountPolicy implements DiscountPolicy{

    int discountPercent = 10; //10프로 할인

    @Override
    public int discount(Member member, int price) { //컨트롤 쉬프트 티 =테스트 클래스 생성 단축키

        if (member.getGrade() == Grade.VIP){
            return price*discountPercent/100;  //vip이면 10할인
        }
            else{
         return  0;
        }
    }
}

새로운 할인 정책 적용과 문제점

새로운 정책 할인 적용 및 테스트

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberMemoryRepository;
import hello.core.member.MemberRepository;

public class OrderServiceImpl implements OrderService{

    MemberRepository memberRepository = new MemberMemoryRepository();

    //DiscountPolicy discountPolicy = new RateDiscountPolicy(); 변경 전 
    DiscountPolicy discountPolicy = new RateDiscountPolicy();  //변경 후

    @Override
    public Order orderCreate(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);


    }

}

테스트

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;


class RateDiscountPolicyTest {

    RateDiscountPolicy rateDiscountPolicy = new RateDiscountPolicy();

    @Test
    @DisplayName("vip 맞을시") //테스트함수명대신 나오는 스트링
    public void 퍼센트할인테스트() {

        Member member = new Member(1L, "승빈", Grade.VIP);  //새로운 멤버 생성

        int discount = rateDiscountPolicy.discount(member, 10000); 

        Assertions.assertThat(discount).isEqualTo(1000); //할인 가격이 1000이 맞는지 확인 
    }

    //성공 테스트도 중요하지만 실패 테스트도 꼭 만들어 봐야한다.

    @Test
    @DisplayName("vip 아닐시")
    public void 퍼센트할인테스트2() {

        Member member = new Member(1L, "승빈", Grade.BASIC);

        int discount = rateDiscountPolicy.discount(member, 10000);

        Assertions.assertThat(discount).isEqualTo(0);
    }
}

새로운정책 테스트

문제점

    //DiscountPolicy discountPolicy = new RateDiscountPolicy(); 변경 전 
    DiscountPolicy discountPolicy = new RateDiscountPolicy();  //변경 후

새로운 정채을 변경할때 새로운 정책의 구현채만 바꾸어주면 되지만 여기에는 아래와 같은 문제점이 있다
- OCP,DIP 객체지향 설계 원칙 위반
  - DIP : OrderServiceImpl클래스는 DiscountPolicy 인터페이스에 의존하면서 DIP를 지킨거같지만 사실은 인터페이스 뿐만아니라 구현 클래스에도 의존하고 있다.
  - OCP: 지금 코드는 기능을 확장해서 변경하려면, 클라이언트 코드에 영향을 준다.

해결 방안

이 문제를 해결하기위해선 누군가가 클라이언트인 OrderService에 DiscountPolicy이 구현 객체를 대신 생성하고 주입해주어야 한다.
(AppConfig라는 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고 , 연결하는 책임을 가지는 별도의 설정 클래스를 만들자!)

관심사의 분리

애플리케이션의 전체 동작 방식을 구성(config) 하기위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들자.

AppConfig

package hello.core;


import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberMemoryRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImp;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

//인텔리제이 단축키 : 컨트롤 e 과거 히스토리나와서 빠르게 화면 전환가능

/*애플리케이션의 전체 동작 방식을 구성(config)하기위해, config 클래스에서 구현객체를 구성하고, 연결하는 책임을
가지는 별도의 설정 클래스를 만든다.*/
/*이전에는 인터페이스의 구현객체가 필요한기능의 구현객체를 직접 new해서 생성했지만,  이제는 AppConfig
클래스가 동작에 필요한 구현객체를 생성한다.*/
//그리고 AppConfig는 생성한 객체 인스턴스의 참조(래퍼런스)를 생성자를 통해서 주입(연결)해준다.
public class AppConfig {

    public MemberService memberService(){
        return new MemberServiceImp(new MemberMemoryRepository());
    }

    public OrderService orderService(){
        return  new OrderServiceImpl(new MemberMemoryRepository(),new FixDiscountPolicy());
    }
}

MemberServiceImpl

package hello.core.member;

public class MemberServiceImp implements MemberService {

    private final MemberRepository memberRepository;

    public MemberServiceImp(MemberRepository memberRepository){
        this.memberRepository = memberRepository;
    }
    // 생성자 주입을 통해서 MemberRepository에 어떤 객체가 들어갈지 결정한다. -> 의존관계에 대한 고민은 외부에서 결정 ->실행에만 집중
        // DIP 완성

    @Override
    public void 회원가입(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member 회원조회(Long memberId) {
       return memberRepository.findById(memberId);
    }

}

OrderServiceImpl

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberMemoryRepository;
import hello.core.member.MemberRepository;

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy){
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;

    }

    @Override
    public Order orderCreate(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);


    }

}

구현체에서 필요한 구현체(기능)들을 AppConfig에서 정해진 구현체를 파라미터로 받아 각각의 인터페이스의 구현체를 할당받았다. 따라서 MemberServiceImpl,OrderServiceImpl은 필요 구현체의 인터페이스만 의존함으로 해당 구현체의 로직에만 집중 할 수 있다. 또 DIP원칙을 지킬 수 있게 된다.

테스트 코드

MemberServiceTest

package hello.core.member;

import hello.core.AppConfig;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;

public class MemberServiceTest {



MemberService memberService;

@BeforeEach  
 public void beforeEach(){
    AppConfig appConfig = new AppConfig();
    memberService = appConfig.memberService();

}

    @Test
    void join(){
        //given
        Member member = new Member(1L,"승빈",Grade.VIP);

        //when
        memberService.회원가입(member);
        Member member1 = memberService.회원조회(1L);

        //then
        Assertions.assertThat(member).isEqualTo(member1);
    }
}

테스트코드에서 @BeforeEach 는 각테스트 코드가 실행되기 전에 실행된다.

테스트코드도 AppConfig에서 memberService()를 호출해 리턴받은 구현체를 memberService에 할당해 테스트한다.OrderServiceTest
package hello.core.order;

import hello.core.AppConfig;
import hello.core.member.*;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class OrderServiceTest {

MemberService memberService;
OrderService orderService;

@BeforeEach
public void beforeEach(){
    AppConfig appConfig = new AppConfig();
    memberService = appConfig.memberService();
    orderService = appConfig.orderService();
}

@Test

void join(){

    //given
    Long memberId = 1L;
    Member member = new Member(memberId, "승빈", Grade.VIP);
    memberService.회원가입(member);

    //when

    Order order = orderService.orderCreate(memberId, "물통", 10000);

    //then
    Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
}

}

- AppConfig에서 memberServic(),orderService()를 호출해 리턴받은 구현체를 memberService,orderService를 할당해 테스트코드에 사용한다.
![Config를 통한 테스트 코드](https://user-images.githubusercontent.com/89888075/163774417-f4327bb2-9a9b-4540-8114-b958741b4dff.PNG)

### 정리
- AppConfig를 통해서 관심서를 확실하게 분리했다.
- 각각의 Impl은  기능을 실행하는 책임만 지면 된다.

<br>
<br>
<br>

# AppConfig 리팩터링

### 리팩터링 전
~~~java
package hello.core;


import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberMemoryRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImp;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {

    public MemberService memberService(){
        return new MemberServiceImp(new MemberMemoryRepository());
    }

    public OrderService orderService(){
        return  new OrderServiceImpl(new MemberMemoryRepository(),new FixDiscountPolicy());
    }
}

리팩터링 전은 전체 구성의 역할이 명확하게 구분이 힘들다.리팩터링 후
package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberMemoryRepository;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImp;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {

public MemberService memberService(){
    return new MemberServiceImp(memberRepository());
}

public MemberRepository memberRepository(){
    return new MemberMemoryRepository();

}

public DiscountPolicy discountPolicy(){
    return new FixDiscountPolicy();
}


public OrderService orderService(){
    return  new OrderServiceImpl(memberRepository(),discountPolicy());
}

}

//리팩토링 해줌으로써 역활이 명확하게 구별된다.

- 리팩터링을 해줌으로서 전체적인 열할을 구분하기 쉬워 졌다.
-new MemberMemoryRepository() 중복이 해결되며 MemberRepository의  구현체 변경이 필요할 경우 구현체만 MemberRepository의 구현체만 바꾸어 주면 된다.
<br>
<br>
<br>

# 새로운 구조와 할인 정책 적용
- 처음으로 돌아가서 정액 할인 정책을 정률% 할인 정책으로 변경해보자.
~~~java
package hello.core;


import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberMemoryRepository;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImp;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {

    public MemberService memberService(){
        return new MemberServiceImp(memberRepository());
    }

    public MemberRepository memberRepository(){
        return new MemberMemoryRepository();

    }

    public DiscountPolicy discountPolicy(){
       // return new RateDiscountPolicy();
        return new RateDiscountPolicy(); // 정률(새로운)할인정책으로 변경
    }


    public OrderService orderService(){
        return  new OrderServiceImpl(memberRepository(),discountPolicy());
    }


}

사용영역 구성영역 구분

AppConfig(구성영역)을 따로 만들어 줌으로 써 기능영역(클라이언트 코드)을 변경할 필요없이 구성영역의 코드만 변경해줌으로써 DIP,OCP원칙을 지키면서 새로운 정책할인으로 변경할 수 있게 되었다.

전체 흐름 정리

새로운 할인 정책 개발
새로운 할인 정책 적용과 문제점
관심서의 분리
AppConfig 리팩터링
새로운 구조와 할인 정책 적용