<aside> ❗

항상 테스트는 성공 케이스와 실패 케이스를 나눠서 진행해야 함

@DisplayName() -

DIP 위반

즉, 구체 클래스에 직접 참조하고 있으므로 DIP 위반

→ 추상에만 의존하도록 변경(인터페이스에만 의존)해야 함

OCP 위반

→ 할인 정책 역할을 변경했는데 클라이언트(OrderServiceImpl) 코드를 변경해야 하므로 OCP 위반

public class OrderServiceImpl implements OrderService{

    // 할인 적용 정책을 변경하려면 OrderServiceImpl 코드를 고쳐야 함
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    // OCP, DIP 위반
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
//    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        // 주문 서비스 입장에서 할인에 대한 것 모르겠다. discountPolicy 니가 알아서 해줘 - 단일 책임 원칙을 잘 지킨 것
        // 즉, 할인 변경을 수행할 때, 할인 쪽만 고치면 됨
        // member 전체를 넘겨도 되고, 등급만 넘겨도 된다. - 상황에 맞게 구현하면 됨
        int discountPrice = discountPolicy.discount(member, itemPrice);

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

</aside>

<aside> ❗

해결

//private DiscountPolicy discountPolicy = new RateDiscountPolicy();
private DiscountPolicy discountPolicy;

단, NullPointException 발생

→ DIP를 지켰지만 문제점 발생 !!

→ 인터페이스에만 의존하도록 구현했지만 NullPointException 발생

**

이를 해결하려면, 누군가 구현 객체를 대신 생성해서 주입해줘야 한다.

</aside>

<aside> ❗

관심사 분리

공연에서 로미오 역할과 줄리엣 역할을 배우가 결정하지 않음 // 기획팀에서 결정할 문제

이전 코드는 로미오 역할(인터페이스)을 하는 배우(구현체)가 직접 줄리엣 역할(인터페이스)을 하는 배우(구현체)를 초빙하는 것과 같음

→ 줄리엣 배우가 공연을 진행함과 동시에 로미오 역할의 배우도 직접 초빙함

→ 줄리엣 배우가 다양한 책임을 가지고 있음

**** 관심사 분리를 통해 책임을 분리

배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 함

→ 상대 배우가 누구건 똑같이 공연할 수 있어야 함

공연 기획자를 만들어서 배우와 공연 기획자의 책임을 확실히 분리해줘야 한다.

** 애플리케이션도 똑같이 구현해야 함

</aside>

<aside> ❗

AppConfig

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

즉, 애플리케이션 전체를 설정하고 구성함

이전 코드는 MemberServiceImpl 구현체가 직접 MemberRepository의 구현체를 선택함

→ AppConfig에서 구현체를 선택하도록 구현

1. MemberServiceImpl 구현체 내부에서 MemberRepository의 구현체를 생성자를 통해서 주입하도록 함

// MemberServiceImpl.java 

// 오로지 MemberRepository 인터페이스만 존재하므로 추상화에만 의존
// 즉, DIP를 지킴 
private final MemberRepository memberRepository;

public MemberServiceImpl(MemberRepository memberRepository) {
    this.memberRepository = memberRepository;
}

→ 구체적인 것은 memberServiceImpl은 모른다. → 밖에서 생성해서 넣어준다. 이를 생성자 주입이라고 한다.

1. AppConfig에서 구현체를 선택하여 주입하도록 구현

// AppConfig.java

// AppConfig에서 생성해서 MemberServiceImpl에 주입
public MemberService memberService() {
    return new MemberServiceImpl(new MemoryMemberRepository());
}

• Appconfig를 통해서 memberService를 불러다 사용
• memberService 구현체 객체 생성
• 이 때, 생성자로 new MemoryMemberRepository() 인자가 전달되어
• memberService의 memberRepository 인터페이스의 구현체가 인자로 전달된 new MemoryMemberRepository()으로 설정된다.

**

MemberServiceImpl 은 어떤 구현체가 선택되어 들어올지 알 수 없다.

MemberRepository 인터페이스에만 의존한다. (더 이상 구현체에 의존하지 않음)

생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정된다.

즉, MemberServiceImpl 은 본인 역할에만 집중하고 있음

**

의존성 주입을 통해 자신의 핵심 로직에만 집중하고, 구체적인 의존 대상에 대한 결정은 외부에서 맡도록 하겠다.

</aside>

<aside> ❗

다음

AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.

AppConfig는 생성한 객체 인스턴스의 참조를 **생성자를 통해서 주입(연결)**한다.

즉, 객체의 생성과 연결은 AppConfig가 담당한다.

그림 - 회원 객체 인스턴스 다이어그램

의존관계 주입(Dependency Injection)

**

관심사 분리를 통해 어떤 객체를 생성(구현체 결정)할지 어떻게 연결할지는 AppConfig가 전담해서 처리

→ 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확하게 분리됨

**

@BeforeEach - 테스트 실행 전에 무조건 실행하게 함

→ 테스트가 2개면 2번 실행 됨 // 각 테스트 독립적으로 실행

</aside>

<aside> ❗

정리

• AppConfig를 통해서 관심사를 확실하게 분리
• 배역, 배우를 생각
• AppConfig는 공연 기획자
• AppConfig는 구체 클래스를 선택한다. 배역에 맞는 담당 배우를 선택한다. 애플리케이션이 어떻게 동작해야 할지 전체 구성을 책임진다.
• 이제 각 배우들은 담당 기능을 실행하는 책임만을 지면 된다. </aside>

<aside> ❗

AppConfig 리팩토링

현재 AppConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 안 보인다.

// new MemoryMemberRepository() 중복
public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
        // MemberRepository 역할이 잘 보이지 않음 
    }

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

• 역할이 들어나게 코드를 작성하는 것이 좋다.

설계

/* MemberService, MemberRepository, OrderService, DiscountPolicy
   역할이 잘 들어나도록 리팩토링
   - 코드만 봐도 역할이 다 들어난다. (설계 그림이 코드에 잘 들어남)
   - 메서드명만 봐도 역할이 다 들어남
   - 역할에 어떤 구현체를 쓰는지 잘 들어남
*/

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

// 나중에 DB로 바꿀 때 return new MemoryMemberRepository(); 부분만 변경하면 됨
private MemberRepository memberRepository() {
    return new MemoryMemberRepository();
}

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

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

• new MemoryMemberRepository() 이 부분이 중복 제거 됨 MemoryMemberRepository를 다른 구현체로 변경할 때 한 부분만 변경하면 됨
• AppConfig를 보면 역할과 구현 클래스가 한 눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되었는지 빠르게 파악 가능 </aside>

<aside> ❗

• AppConfig 등장으로 애플리케이션이 크게 사용 영역과 객체를 생성하고 구성하는 영역으로 분리

• 할인 정책을 변경하고자 할 때, AppConfig만 변경하면 된다.

** 할인 정책을 변경해도 구성 영역만 영향을 받고, 사용 영역은 영향을 받지 않게 됨

// 이전 코드 
public DiscountPolicy discountPolicy() {
    return new FixDiscountPolicy();    
}

// 할인 정책 변경 코드 
public DiscountPolicy discountPolicy() {
    return new RateDiscountPolicy();  // 해당 라인만 변경하면 쉽게 할인 정책 변경
}

• 단순히 FixDiscountPolicy를 RateDiscountPolicy 객체로 변경
• 할인 정책 변경 시 AppConfig만 변경하면 된다.
• 즉, 사용 영역의 어떤 코드도 변경할 필요가 없다.
• 구성 영역은 당연히 변경 됨, AppConfig는 모든 구현 객체들을 알아야 한다.

**

클라이언트 코드를 전혀 수정하지 않고도 애플리케이션 기능 확장 가능 !!

OCP, DIP 모두 만족

</aside>

<aside> ❗

전체 흐름 정리

클라이언트 코드가 너무 많은 역할을 함

→ 관심사 분리 수행

기존 - 클라이언트가 의존하는 서버 구현 객체를 직접 생성하고 실행 → 공연 배우가 본인의 배역뿐만 아니라 상대 배역을 직접 결정

AppConfig 등장

애플리케이션 전체 동작 방식을 구성하기 위해, 구현 객체를 생성하고 연결하는 책임 수행

클라이언트 객체는 자신의 역할을 실행하는 것에만 집중, 즉 권한이 줄어듦(책임이 명확해짐)

AppConfig 리팩토링

구성 정보에서 역할과 구현을 명확하게 분리

역할이 잘 들어나게 함

중복 제거

새로운 구조와 할인 정책 적용

정액 할인 정책을 정률 할인 정책으로 변경

AppConfig 등장으로 애플리케이션이 사용 영역과 구성 영역으로 분리 됨 할인 정책을 변경해도 AppConfig가 있는 구성 영역만 변경하면 됨

→ 사용 영역은 전혀 변경할 필요가 없음

→ 클라이언트 코드인 주문 서비스 코드도 변경하지 않음

**

AppConfig가 애플리케이션 전체 동작 방식을 구성한다는 말의 의미

→ 어떤 구현체들을 사용하여 애플리케이션 로직을 수행할 것인지 정하고 그 구현체들을 어떻게 연결(주입)해서 애플리케이션이 동작하도록 만들지 결정한다는 의미

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>