AppConfig의 등장
- 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들자
- AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다
- AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다
MemberServiceImpl(멤버서비스 구현체) 이전코드
구현체가 직접 어떤 저장소를 사용할지 너무나도 구체적으로 지정하는 모습이다.
인터페이스에만 의존하는것이 이상적인 모습이다
new코드
따라서 위와 같이 기존 코드를 지우고 생성자를 만들어 준다
Appconfig
Appconfig에 위와 같이 만들어준다
이러면 어디선가 Appconfig를 통해 MemberService를 불러다 쓸텐데 그때 멤버서비스 구현체가 생성이 되는데 메모리멤버 리포지토리(저장소)도 새로 생겨서 넣어진 채로 반환이 됨 (생성자 주입)
Order Service imple 기존코드
new 코드
Appconfig
이제 OderService를 불러다 쓸 때 OrderServiceImpl이 뒤에 2개가 생성되어 넣어진 채로 반환이 될 것이다
위의 Appconfig를 보면 구동에 필요한 구현체인
1. Member Sercive Impl
2. Memory Member Repository
3. Order Serive Impl
4. Fix Discount Policy
모두 생성이 되는것을 볼 수 있다
이는 생성된 구현체 객체들을 생성자를 통해 주입 하는 모습이고
이를 생성자 주입이라고 함
이렇게 되면 interface에만 의존하게 될 수 있다
객체의 생성과 연결은 Appconfig가 담당한다
너네는 interface만 신경써
test도 바꿔주도록 하자
멤버서비스 test 기존코드
멤버서비스 test 수정된 코드
@BeforeEach : 가장먼저 실행되도록
memberService는 상단에 선언 해두고
아래의 AppConfig를 통해 memberSerivice를 받아오는 모습
OrderService test도 같은 방법으로 하면 된다 (생략)
AppConfig 리팩터링
Appconfig 수정 전
지금 보면 뭔가 복잡하고 역할이 한 눈에 안보인다
그리고 MemoryMemberRepository 가 중복이여
Appconfig 수정 후
이렇게 따로따로 빼주면 메소드 명을 보고 역할을 알 수있고 어떤 구현체를 쓰는지 한 눈에 보임
- 멤버서비스라는게 있고 그것은 멤버서비스impl 이라는 구현체로 쓰는군
- 멤버리포지토리는 지금 저걸 쓰고있는데 나중에 jdbc로 바뀌면 저 코드만 수정해주면 되겠군
등등
그래서 이제 fix할인정책에서 rate할인정책으로 바꾸려고하면 아래와 같이 Appconfig에서만 수정을 해주면 되는것임
제어의 역전 (IoC)
예를 들어 OrderServiceImpl 같은 경우 어떤 구조체를 사용할지 직접 선택을 했었는데 Appconfig가 등장한 후로 OrderServiceImpl은 제어권이 없어짐 그냥 Appconfig가 주는대로 사용할 뿐
이렇게 프로그램의 제어흐름을 직접 자기가 하지 않고 외부에서 관리되어 지는것을 제어의 역전(IoC) 라고 한다
test 실행 하는것도 JUnit이 다 해주는거라 제어의 역전임
의존관계 주입 (DI)
우선 의존관계는 정적인 클래스 의존 관계와 실행 시점에 결정되는 동적인 객체 의존 관계를 분리해서 생각해야함
정적인 클래스 의존관계
import 코드만 보고 의존관계를 쉽게 판단 가능
애플리케이션을 실행 하지 않아도 분석할 수 있음
아래의 클래스 다이어그램을 보면 화살표가 "의존하고있다" 라는 의미인데
OrderServiceImpl이 3개의 인터페이스를 의존하고 있고
각 구현체들은 각자의 인터페이스를 의존하고 있는 모습을 볼 수 있는데
이건 애플리케이션을 실행 하든 하지않든 고정되어있음
그래서 정적인 의존관계라고 하는 것
동적 의존관계 보면 더 와닿을 것임
동적인 객체 인스턴스 의존 관계
애플리케이션 실행 시점에 생성된 객체 인스턴스의 참조가 연결된 의존관계임
아래 AppConfig의 코드를 보면 이해가 빠름
앱이 실행될 때 OrderServiceImpl이 생성되고 이 OrderServiceImpl은 생성된 memberRepository 랑 discountPloicy를 의존하고 있는 모습
즉, 앱이 실행될 때 생성된 객체들의 의존관계를 의미하는 것
위의 코드를 다이어그램으로 표현한 것임
그래서 AppConfig 같이 객체를 생성하고 관리하고 의존관계를 연결해 주는것을 IoC컨테이너 or DI컨테이너라고 부른다
요즘은 DI컨테이너 라고 많이 한다고 함
스프링으로 전환하기
Appconfig에 가서
@Configuration을 붙여주고
각 메소드 위에 @Bean을 붙여준다
그렇게 해주면 키와 값으로 스프링 컨테이너에 등록이 된다
->(Key:메소드 이름 / value: 생성되는 인스터스)
이렇게 스프링 컨테이너에 등록된 객체들을 스프링 빈 이라고 함
OrderApp (만든 주문할인정책이 제대로 되는지 실행해 보는 곳)
기존코드는 아래와 같다
변경 된 코드
ApplicationContext를 스프링 컨테이너 라고함
applicationContext.getBean()을 이용해서 메서드를 찾을 수 있음
->applicationContext.getBean(불러올 메서드이름, 타입)
지금까지는 Appconfig에서 직접 해줬는데
이제부터는 스프링 컨테이너에 Appconfig에 있던 메서드들을 등록해서 사용하게 될것임
