IoC (제어의 역전)

프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것.

보통 제어라는 건 본인이 스스로 하는 것이 자연스러운데, 제어의 역전이라는 말은, 내가 짠 코드자체가 제어권한을 가지는 것이 아니고 외부에서 제어권한을 가지는 것을 의미한다. = 말그대로 제어의 흐름이 역전이 된다는 것이다.

내가 구현한 객체는 자신이 가지고 있는 로직의 결과가 어떻게 되는지 알지 못한다. ⇒ 제어흐름의 권한을 외부에서 가지고 있기 때문이다.

여기서 말하는 외부는 흔히는 프레임워크가 된다.

💡 프레임워크 vs 라이브러리 ??

제어의 권한을 가지는 것이 프레임워크. 
  ex) 스프링, 하이버네이트, 장고, JUNIT, AssertJ 등... 

권한을 가지진 않고 , 짜여진 로직이 담겨있는 것은 라이브러리.

DI (의존 관계 주입)

애플리케이션 실행시점에(런타임) 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결이 되는 것.

💡 의존관계 한 쪽이 다른 한 쪽의 영향(의존)을 받는 관계.
=> 한 쪽의 변화가 다른 쪽에 영향을 주게되는 관계.

• 객체 인스턴스를 생성하고 , 그 참조값을 전달해서 연결된다.
• 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공해줌으로써 만들어진다.
• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
• 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.
  (구성된 의존관계의 틀을 벗어나지 않고, 변경되지 않고, 객체 인스턴스 값만 변경을 해주면 의도한 대로 변경된 값을 참조하며 작동한다.)

💡인터페이스를 활용하면 의존관계 주입을 느슨하게 만들어 주어 변경에 자유로워 질 수 있다.
⇒ 변화가 없어야하는 부분을 건들이지 않으면서 특정값을 더 손쉽게 변경할 수 있게된다.
⇒ 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않아야하기 때문에 인터페이스를 활용하여 느슨한 의존성을 만들어준다.

컨테이너

컨테이너라는 단어를 들으면 무엇이 떠오는가? 나는 무언가가 담기는 상자가 생각이 난다. 여기서 사용되는 컨테이너라는 용어도, 어쩌면 비슷한 의미로 명명을 해준것이 아닐까 생각이 든다.

우리가 이곳저곳에서 참조하며 사용하게 될 메서드나 로직 등을 컨테이너에 담아주고 , 해당 코드들을 사용해야하는 순간에 해당 메서드를 가진 클래스를 임포트하거나 할 필요없이 컨테이너에서 꺼내 사용을 하면 된다.

컨테이너가 클래스와 클래스, 인터페이스와 클래스 등,, 정보를 주는 곳과 꺼내는 곳 사이의 배달부라고 생각 할 수도 있을 것 같다.

한마디로 말한다면, 제어의 역전을 일으켜, 제어권한을 가지는 곳.

(그래서 IoC컨테이너 라고도 하고, 의존관계를 주입해주기도 해서 DI컨데이너라고도 한다. 최근에는 DI컨테이너라고 한다고 한다.)