wiring metadata가 있고 그걸 이용해 프레임워크가 이어줘야만 IoC라고 생각하는 사람들이 있는데 그렇지 않음


본질적으로 DI는 함수형 언어에서 고차 함수가 다른 함수의 자리를 남겨 놓는 거랑 동일한 원리임 (대상은 다르지만)


오해가 생긴 건 스프링 컨테이너가 사용자가 메타데이터를 남기면 그걸 토대로 bean을 찾아 연결하는 방식을 택하기 때문인데

초기 IoC 컨테이너들은 그렇지 않고서도 다른 방법을 얼마든지 채택할 수 있었음

마틴 파울러가 초기 형태의 IoC 컨테이너들을 비교 분석하고 DI가 아닌 다른 방식 설명한 글이 있는데 읽어보면 도움이 될거임


https://www.martinfowler.com/articles/injection.html


어쨌든 어디선가는 분명 와이어링을 해줘야 하고, 그걸 사용자가 직접 코드로 연결하더라도 DI라고 할 수 있음

그러므로 DI의 아이디어 자체는 함수형 언어로부터 나왔고(LISP), 객체지향 언어에 접목된 것은 스몰토크 MVC에서 유래했음

https://stackoverflow.com/questions/243905/smalltalk-and-ioc


객체지향 관점에서 다시 설명하자면 DI의 핵심은 내가 할 일을 프레임워크가 대신 해준다가 아님.

의존 관계에 놓인 객체들이 서로를 직접 생성하거나 찾아내지 않게 해서

결과적으로 의존되는 클래스의 변경으로 인해 실제 의존하는 객체가 못쓰게 되는 일을 방지하려는 거임

그렇기 때문에 그 객체들이 아닌 어디서라도 의존을 충족시켜줄 수 있다면 IoC 구조라고 할 수 있음


꼰대 소리 좀 하자면

이런 개념은 쉽게 이해하려고 하면 곡해하기 쉽고 와닿지 않을 가능성이 높다(밑에 DI 간단하게 설명해보라는 사람 보고 하는 말임)

그렇기 때문에 쉬운 글만 찾아 읽지 말고 다양한 자료들을 보면서 전체적인 그림과 핵심 세부사항을 머릿속에 쌓는 게 현명한 공부다.