스프링 핵심 원리 이해1

• 현재 코드의 문제점

테스트 코드

public class MemberServiceTest {
    MemberService memberService = new MemberServiceImpl();
    //지금 추상화뿐만 아니라 구체화까지 의존을 하고 있는 형태 - dip 위배

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

        //when
        memberService.join(member);
        Member findMember = memberService.findMember(1L);
        //then
        Assertions.assertThat(member).isEqualTo(findMember);
    }
}

=> MemberService memberService = new MemberServiceImpl();

• 지금 추상화뿐만 아니라 구체화까지 의존을 하고 있는 형태 => 이는 구현체에 의존하지 않고 추상화에 의존해야한다는 dip 위배

---

할인 정책 변경에 유연하게 설계할 수 있도록 코드를 짠다는 것

public class OrderServiceImpl implements  OrderService{

    private  final MemberRepository memberRepository = new MemoryMemberRepository();
    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);
        //설계가 잘된 이유 : 할인과, 주문의 책임이 잘분리됐기 떄문
        // 할인의 로직이 바뀌면 할인 쪽만 가서 변경해주면 된다.
        // 할인은 딱 할임만 주문은 할인에 관여하지 않기 때문에 책임과 역할이 잘 나눠짐

        //discount Policy 가 없었다면, 할인 로직을 order 에서 수행해줬어야 한다

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

}

• 단일 책임만 지도록 설계한 것
• 할인의 로직이 변경되어도 , order의 로직은 변경하지 않아도 되는 상태 => 바람직