https://justhackem.wordpress.com/2016/05/13/dependency-inversion-terms/?fbclid=IwAR3QHnlZVoiBgv-UlxSb6WclQSxmJJ8LiXou6yAz3aBUySeFNKqJx31NMsk
의존성 역전 원리(Dependency Inversion Principle)는 모듈간 낮은 결합도(loose coupling)와 테스트 용이성(testability)을 확보하는데 유용한 디자인 방법입니다. 저는 확장 가능하고(scalable) 클라우드 환경에 적응력있는(adaptive) 응용프로그램 디자인을 위해 의존성 역전 원리가 아주 큰 역할을 한다고 생각합니다. 하지만 안타깝게도 의존성 역전 원리와 관련된 기법과 도구를 지칭하는 용어들은 자주 혼동됩니다. 용어가 혼동된다는 것은 그 대상의 의미도 혼동되고 있다는 뜻입니다. 의미를 혼동하면 필요한 곳에 적절히 사용할 수 없겠죠. 의존성 역전 원리에 대한 이해를 돕기 위해 관련된 주요 용어들을 간단히 정리했습니다. 설명 대상 용어에 대해서는 번역된 표현 대신 영어 원문을 그대로 사용했습니다.
IoC는 전통적인 방식에 반대되는 흐름으로 코드가 진행되는 것을 말하는 일반적인 용어입니다. Dependency Injection과 많이 혼동되는데 다른 개념입니다. 오히려 Dependency Inversion Principle이 IoC의 한 형태입니다.
아주 가끔씩 IoC를 Dependency Injection과 동일한 축소된 의미로의 사용을 허용하는 모습을 볼 수 있는데 저는 이것이 아주 맘에 들지 않습니다. Martin Fowler는 이것과 관련해 이런 말을 했습니다. “Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.”
라이브러리와 프레임워크의 관계는 IoC를 설명하는 단골 예입니다. 라이브러리를 사용할 때는 내 코드가 라이브러리 코드(외부 코드)를 호출하지만 프레임워크를 사용할 때는 프레임워크(외부 코드)가 내 코드를 호출합니다. 상호작용(interactive) 프로그래밍 모델과 반응형(reactive) 프로그래밍 모델도 하나의 예입니다.
IoC는 헐리웃에서 오디션이 끝난 후 오디션 참가자에게 하는 말때문에 Hollywood Principle로 불리기도 합니다.
Don’t call us, we’ll call you.(합격했는지 귀찮게 자꾸 전화하지마. 합격하면 우리가 너한테 연락할꺼야.)
다음 IoC에 대한 설명을 참고하세요.
별도의 게시물로 IoC에 대해 좀 더 정리했습니다.
Dependency Inversion Principle은 의존관계를 갖는 모듈 인스턴스의 구성이 추상화에 의존하는 것을 뜻합니다. 말이 조금 어려운데 사전적 정의는 더 어렵습니다.
의존 주체 모듈 인스턴스가 의존 대상 모듈 인스턴스를 직접 생성하는 것을 전통적 흐름이라고 하면 이 전통적 흐름에서는 의존 대상 코드의 형식이 의존 주체 코드에 의해 결정되기 때문에 의존 대상 코드의 다형성이 동작하기 어렵습니다. 반면 Dependency Inversion Principle이 사용되면 구체적인 의존 관계가 추상화에 의해 런타임에 결정되기 때문에 다형성을 적극적으로 활용할 수 있으며 모듈의 재사용성이 높아집니다.
Dependency Inversion Principle을 설명하기 위해 문서 편집기(DocumentEditor, 의존 주체)와 문서 저장 기능을 제공하는 인터페이스(ISerializer, 의존 대상) 및 구현체를 정의합니다.