AppConfig

https://salmon16.tistory.com/75

OCP, DIP 원칙이 위배되는 역할과 구현 분리

위 링크 문제를 해결하기 위해 구현 객체를 생성하고 연결하는 AppConfig클래스를 만들자.

Appconfig는 구현 객체를 생성하여 return 해 준다.

여기서 MemoryMemberRepository()의 인스턴스는 다르지만 이 속의 Map이 static으로 만들어 졌기 때문에 인스턴스 끼리 공유가 돼서 데이터 불일치 문제는 신경 안 써도 된다.

이렇게 작성을 하고 각 Impl클래스의 생성자를 추가하면 OCP, DIP를 위배하지 않게 만들 수 있다.

예로 MemberServiceImpl 코드를 보면

더 이상 구현에 의존하지 않고 오로지 인터페이스만 의존한다. 이를 그림으로 표현하면 아래 처럼 된다.

memberServiceImpl 입장에서 보면 외부(appConfig)에서 의존관계를 실행시점에 주입해 준다.  이를 DI (Dependency Injection)이라고 한다.

 

이제 테스트 코드를 이용하여 테스트를 해보자

이렇게 AppConfig를 생성 후 memberService를 받아와서 사용하면 된다.

@BeforeEach는 테스트 코트를 수행하기 전에 먼저 수행하는 코드이다. 

 

이렇게 작성하면 구현 부분을 바꾸더라도 클라이언트 부분을 수정 안 하고 AppConfig부분만 바꾸면 된다

프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)라고 한다.

AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC컨테이너 또는 DI 컨테이너 라고 한다.

출처 : 인프런 스프링 핵심 원리 - 기본 편  김영한