Inversion of Control (IoC) is a very nice concept, one of my favourite. It helps easily extend existing code without need to make change to the extended library. It is based on an idea of injecting class dependency into an object oriented code. What does it mean?
There is many posts on the Net with subject Inversion of Control (IoC). Shortly it means exactly what it says: the pattern inverses the way how objects controls other objects. The straightforward way of using other object is to create it directly with constructor. The other way (in IoC manner) is to request/gain the object from someone else.
Nice simple example can be seen here.
This concept is not new to many developers. For example about 18 years ago this concept was used in Turbo Vision to create text user interface:
TMenuBar *newMenu = new TMenuBar( r,
*new TSubMenu( "~\360~", kbAltSpace ) +
*new TMenuItem( "~A~bout", cmAbout, kbAltA, hcNoContext ) +
// this TMenuItem will bring up another menu
*new TMenuItem( "Exit", 0, new TMenu(
*new TMenuItem( "Exit & ~S~ave", cmQuit, kbAltX, hcNoContext, 0,
new TMenuItem( "Exit & ~A~bandon", cmQuit, kbAltY, hcNoContext, 0,
new TMenuItem( "Just ~Q~uit", cmQuit, kbAltZ, hcNoContext, 0,
new TMenuItem( "~N~ext Level", 0, new TMenu(
*new TMenuItem( "~O~ne", cmQuit, kbAltX, hcNoContext, 0,
new TMenuItem( "~T~wo", cmQuit, kbAltX ))))
However I think that in these days the concept is more important than ever. It is so important that I recommend to think about it a little. What it can bring to us today?
Every customer has different needs
First, it may solve the problem of customizations. Think that you have a software which you sell to many customers. The problem is that every customer wants the software to behave in a different manner and if you have dependencies between classes hard coded using constructors you have only 2 choices. You may tell the customer that the software doesn’t support this behavior, because the change will influence other customers when you give them upgrade. When you say this you may loose the customer.
Probably you change the software. However you need to make the change only for this customer so you create a copy of the source code and make changes in the copy. Now you have a separate copy of a software for each customer and everybody is happy. Except a developer, who must keep many programs up to date (think that every copy is independent program). Copy and paste approach raises many problems for example bug fixing.
IoC (along with good object oriented design) allows developers not to make source code copies. Instead of copying developers are able to take advantage of inheritance. With IoC concept you can inherit the class, change its behaviour and let dependent objects use instances of your inherited class. Sounds good, doesn’t?
Error free upgrades
Another problem is quality. If you have a complex software it’s very hard to keep it in a good quality (so without errors) while you add new features. Any change in the software may arise to a problem because a small change in one class may cause an error in another dependent class. How can IoC help us to solve this problem? The solution to this is not IoC itself but it’s unit testing. And in unit testing is IoC very important.
Unit test is piece of code which tests output of methods and classes. Proper unit test needs a tested class to have good object oriented design and it must use IoC. Then the unit test is able to run very fast (milliseconds) and it ensures that the class remains in a good condition after you’ve made a change in it. Unit tests must test functionality of a single class not the whole underlying framework so you need to simulate dependent objects and here is the IoC concept important, because in unit testing you usually create fake/mock objects on which tested classes depends.
You may see that the Inversion of Control concept becomes more and more important, because developers are pushed by customers to deliver programs in some quality and flexible enough to meet individual customer requirements. However the concept is not the only solution. The code needs to meet object oriented design mainly it must use encapsulation of its inner fields. It’s not difficult to achive this encapsulation. You can use many of refactoring methods to clean smelly code, but this is not goal of this post.
If you found my article useful you can continue to read what Martin Fowler writes about Inversion of Control.
I wish you happy coding