Nie chcę brać udziału w tej dyskusji bo to chyba 50-ta z tej serii, nie chcę też tworzyć jakichś ulotnych i łatwo podważalnych definicji, ale chciałbym wyprostować jedno pojęcie.
Podano tu nieścisłe twierdzenia o IoC:
IoC to jest forma DI. DI oznacza że przez konstruktor wstrzykujesz zależności np:
- DI to sposób realizacji IoC -> wstrzykujemy do modułów implementacje, z których one, poprzez jasno zdefiniowany interfejs, korzystają. Ale to nie jest jedyne rozwiązanie, jakiś ServiceLocator czy Factory też może być realizacją IoC.
Pracowałem z frameworkiem IoC w COBOLu. Tam nie ma konstruktorów, setterów ani interfejsów.
Prosta i krótka definicja: IoC inverts the flow control as compared to traditional control flow
Źródło: https://en.wikipedia.org/wiki/Inversion_of_control
Coś takiego można też zrobić w dowolnym innym języku. IoC można np. zauważyć przy odpalaniu skryptów /etc/init.d gdzie o przepływie sterowania decyduje "framework" a nie skrypt znajdujący się w tym katalogu.
Ogólnie DI nie ma w podstawowym znaczeniu związku z IoC.
IoC nie wymaga DI a samo DI (np. przez konstruktor) często jest realizowane bez IoC.
Przykład: https://hackernoon.com/you-dont-need-a-dependency-injection-container-10a5d4a5f878
Dopiero na poziomie kontenera oba te terminy mogą się spotkać, np. w takim Springu - tam kontener wie tak dużo o module że może mu grzebać w bebechach bez wiedzy wybranego obiektu.
Ogólnie bliższe mi jest znaczenie z wiki niż takie odwołujące się w każdym zdaniu (pośrednio lub bezpośrednio) do Springa:
The term is related to, but different from, the dependency inversion principle, which concerns itself with decoupling dependencies between high-level and low-level layers through shared abstractions. The general concept is also related to event-driven programming in that it is often implemented using IoC, so that the custom code is commonly only concerned with the handling of events, whereas the event loop and dispatch of events/messages is handled by the framework or the runtime environment.