본문 바로가기

Programming

DI 와 IoC 에 대한 개념과 스프링

https://github.com/itdar/TIL/blob/main/books/Toby_Spring3.1_vol.1.md

 책의 2회독째 3ch 부근에서 확 와닿게 정리되는 문장을 보아서 그냥 줄줄 써본다.


 전체 정리를 먼저 해본다면,

IoC 는 Inversion of Control, 제어의 역전 이라는 뜻을 갖는다. IoC 컨테이너는 그 기능을 하는 것이고,

이는 객체지향적인 코딩을 하는데에 불편한? 필요한? 것들을 없애주고 제공해준다. 이 때, IoC 의 기반이 되는 것이 DI 이다.

DI 는 Dependency Injection, 의존관계 주입인데 이를 통해서 IoC 가 구현 될 수 있는 것이다.

 

- IoC 가 뭘 제어한다는 것인가?

객체의 생성과, 생성한 객체 간의 의존관계 설정에 대한 것을 제어 한다는 것이다.

 

- 그럼 뭐가 역전되었다는 것인가?

단순히 클라이언트가 필요에 따라 사용할 객체들을 생성하고 의존관계 설정해서 사용을 할 수 있다.

클라이언트는 생성과 의존관계 설정에 관심을 두지 않고 필요한 객체만 제 3자에게 받아서 사용한다. 

 

- 여기서 제 3자에게 제어권이 역전되어 넘어갔다는 것인데, 제 3자는 누구인가?

단순하게는 팩토리가 될 수도 있을테고, 대표적인 프레임워크로 본다면 스프링프레임워크의 빈팩토리 (스프링컨테이너, IoC 컨테이너 ...) 가 될 수 있겠다.

 

- 왜 제어권을 IoC 컨테이너 같은 제 3자에게 넘겨야 하는가?

객체지향의 원리를 고민하는, 즉 유지보수가 용이한, 미래를 고려한, 설계와 구현을 고민하면서 나오는 문제를 해결하는 일종의 방법이 될 수도 있다.

관심사의 분리 (생성, 관계설정, 기능동작 등) 가 될 수도 있겠다.

 

- 그렇다면 DI 는 뭔데 스프링 얘기 할 때 항상 세트로 언급되는가?

IoC 를 구현하려면, DI 가 필요하다.

 

- 그럼 DI 는 무엇인가?

DI 는 Dependency Injection, 의존 주입, 의존관계 주입, 의존객체 주입 의 뜻을 갖는다.

객체와 객체의 관계를 설정하는데, 생성자(Constructor)/수정자(Setter) 등을 통해 객체 레퍼런스를 입력받아서 설정한다.

 

- DI 는 왜 쓰는건가?

객체끼리 어떻게 연결해서 사용할 지 정해줘야하니까.

근데 객체와 객체를 정적인 컴파일타임에 설정하는 것이 아니라, 동적인 런타임에 설정 할 여지를 남겨둔다. (고정된 것이 아니고 주입을 받으니까)

 

- 그래서 그게 IoC 랑 DI 랑 무슨 관련인가?

IoC 컨테이너에서 관리하는 객체들이 관계를 맺으려면, 컴파일 타임에서 관계가 없으니 어쩔 수 없이라도 런타임에 주입을 받아야지!

DI 할 코드 (생성자, 수정자) 가 없으면 관계를 못 맺으니까.

 


 예전 회사에서 일하면서 요구사항 바뀌는 것이 잦아서 외부 xml 로 내부 인터페이스 구현체를 바꾸도록 해서

장비 사용 시나리오나 알고리즘의 설정을 변경 할 수 있게 했던 적이 있는데, 그게 IoC 컨테이너 개념이었던 것 같다.