관심사의 분리

애플리케이션을 하나의 공연이라 생각해보자
각각의 인터페이스를 배역이라고 생각하자
배역을 정하는 것은 배우가 아니다
이전까지의 코드는 배우가 배역까지 직접 정하는 것과 같았다

관심사를 분리하자
- 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다
- 배우는 어떤 파트너가 선택되더라도 똑같이 공연을 할 수 있어야 한다
- 공연을 구성하고, 담당 배우를 섭외하고,
  역할에 맞는 배우를 지정하는 책임을 담당하는 별도의 '공연기획자'가 필요하다
- 공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실히 분리하자

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

 

MemberServiceimpl 에서 MemberRepository에 대한 생성자를 만든다

AppConfig의 코드를 다시 살펴보자

 

public MemberService memberService(){
        return new MemberServiceimpl(new MemoryMemberRepository());
    }

 

이 코드를 사용하면 memberService가 호출될 때 MemoryMemberRepository 객체를 생성하여
MemberServiceimpl 에 작성한 생성자에 반환한다
공연 기획자의 역할인, 배우와 배역을 지정하는 책임을 AppConfig이 전담하는 것이다
이렇게 하면 MemberServiceimpl 에서는 구현체가 전혀 코드에 섞이지 않았으니, 문제를 해결했다

그 원리에 대해 분석하기로는, AppConfig 클래스가 다른 패키지 보다 상위에 있기 때문에 먼저
실행되어 return한 클래스로 리턴값이 세팅 되는 것으로 보인다

이런 방법을 '생성자 주입(DI)' 이라고 한다

OrderServiceimpl 도 마찬가지로 생성자 주입을 사용하자
여기는 두개의 구현체를 사용하고 있으니, 생성자도 두개를 만들어 준다
보통 final이 붙으면 어떤 방식으로든 할당이 되어야 한다

 

AppConfig에도 추가

 

테스트 할 시간이다

 

AppConfig를 불러와서 멤버 서비스를 꺼낸다

더이상 직접 MemberSerivceimpl 에 의존하지 않아도 된다

 

Order 도 마찬가지

사용할 메소드를 AppConfig에서 불러와 사용하면 된다

 

테스트 코드도 당장 돌려보면 오류가 난다

이렇게 수정해 주자

 

@BeforeEach를 사용하면 클래스를 실행하기 전에 먼저 해당 메서드를 세팅 한다

내가 기억하기로는 아마 테스트 코드는 빨리 완료되는 순서대로 결과를 내기 때문으로 알고 있다

코드가 맞더라도 의존관계가 달라지면 실패가 뜰 수도 있기 때문에, 필수적으로 세팅해줘야 하는 것에 위 같은 방법을 사용한 것으로 기억한다

 

여기도 고쳐주고 각자 실행, 전체 실행 모두 성공했다

이제 DIP를 지키게 되었다