AppConfig과 IoC, DI

앞선 포스터 https://nologic-07.tistory.com/44 에서 Spring이 OCP와 DIP를 지키는 방식에 대해 얘기했다.

Spring에서는 AppConfig 라는 이름의 설정 코드(xml, java ....)를 대체로 쓰는 것 같다. 

이 AppConfig의 등장으로 애플리케이션은 사용영역(실제 코드)와 객체를 생성하고 구성하는 구성영역(App Configuration)으로 나뉘게 된다. 

이제 실제 코드에서는 자신에게 어떤 구체 클래스가 들어오는지도 모르는 채로 그저 AppConfig에서 만들어주는 빈을 받기만을 기대하면 되는 것이다. 이것이 의존 관계 주입을 통한 제어의 역전(IoC)이다. 

 

이런 동작방식은 AppConfig가 프로그램의 제어흐름을 가지게 된다. 구현 객체들은 그저 자신의 로직을 실행하는데만 집중하게 된다.

밑의 예시를 보면, AppConfig가 어떤 객체를 만들지 결정하고 있고, Controller는 그것을 주입받고 있다. 

 이때 Controller는 자신에게 필요한 인터페이스를 호출하지만, 어떤 구현객체가 실행될 지 모른다. 

MemberService는 어떤 구현 객체가 실행될 지도 모르고, 나아가 자신이 주입받은 객체들이 어떠한 역할을 수행할 지도 모른다. 그저 자기자신(Controller)의 역할(로직)을 수행할 뿐이다. 

 

이처럼 프로그램의 제어흐름을 직접 제어하지 않고, 외부에서 관리해주는 것이 IoC이다.

 

이런 역할을 하는 프레임워크와 라이브러리는 어떤 역할을 대신 해 준다는 점에서는 공통점이 있지만,

프레임워크는 내가 작성한 코드를 제어하고 대신 실행하는 반면에

라이브러리는 내가 라이브러리를 호출해서 어떠한 처리를 맡기고, 값을 돌려받아 필요한 처리를 내가 한다. 

 

의존관계 주입(DI)

위의 그림에서 AppConfig를 보면 MemberService는 MemberRepository라는 의존관계를 주입받는다. 

즉 MemberService를 구현하는 객체들인 MemoryMemberService, JDBCMemberService는 실제 코드에서 MemberRepository 인터페이스를 의존하고 있을 것이다. 

이 또한 실제 코드에서 MemberService 구현 객체들은 MemberRepository에 어떤 구현객체가 사용될 지 모른다.

 

의존관계는 정적인 클래스 의존관계와 동적인 객체 의존관계가 있다.

import만 보고도 의존관계를 분석할 수 있다면 정적인 클래스 의존관계이다. 또한 클래스 다이어그램을 보고 분석할 수 있다. 

반면 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스와 참조가 연결된 의존 관계인 경우에는 import나 클래스 다이어그램을 보고 분석할 수 없다. 이는 객체 다이어그램을 보고 분석할 수 있다. 

 

AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 존재가 IoC컨테이너, DI컨테이너, Spring 컨테이너라 불린다. 의존관계 주입에 초점을 맞추어 주로 DI 컨테이너라 불린다.