Inversion of Control (IoC) can be quite confusing when it is first encountered.
Inversion of Control (IoC) is a design principle that allows classes to be loosely coupled and, therefore, easier to test and maintain. IoC refers to transferring the control of objects and their dependencies from the main program to a container or framework.
Inversion of Control is a principle in software engineering which transfers the control of objects or portions of a program to a container or framework. We most often use it in the context of object-oriented programming.
Dependency Injection was originally called Inversion of Control (IoC) because the normal control sequence would be the object finds the objects it depends on by itself and then calls them. Here, this is reversed: The dependencies are handed to the object when it's created.
The Inversion of Control is a fundamental principle used by frameworks to invert the responsibilities of flow control in an application, while Dependency Injection is the pattern used to provide dependencies to an application's class.
The Inversion-of-Control
(IoC) pattern, is about providing any kind of callback
(which controls reaction), instead of acting ourself directly (in other words, inversion and/or redirecting control to external handler/controller). The Dependency-Injection
(DI) pattern is a more specific version of IoC pattern, and is all about removing dependencies from your code.
Every
DI
implementation can be consideredIoC
, but one should not call itIoC
, because implementing Dependency-Injection is harder than callback (Don't lower your product's worth by using general term "IoC" instead).
For DI example, say your application has a text-editor component, and you want to provide spell checking. Your standard code would look something like this:
public class TextEditor { private SpellChecker checker; public TextEditor() { this.checker = new SpellChecker(); } }
What we've done here creates a dependency between the TextEditor
and the SpellChecker
. In an IoC scenario we would instead do something like this:
public class TextEditor { private IocSpellChecker checker; public TextEditor(IocSpellChecker checker) { this.checker = checker; } }
In the first code example we are instantiating SpellChecker
(this.checker = new SpellChecker();
), which means the TextEditor
class directly depends on the SpellChecker
class.
In the second code example we are creating an abstraction by having the SpellChecker
dependency class in TextEditor
's constructor signature (not initializing dependency in class). This allows us to call the dependency then pass it to the TextEditor class like so:
SpellChecker sc = new SpellChecker(); // dependency TextEditor textEditor = new TextEditor(sc);
Now the client creating the TextEditor
class has control over which SpellChecker
implementation to use because we're injecting the dependency into the TextEditor
signature.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With