IoC or Inversion of Control.
A well known example of the
IoC pattern is the Windows 3.0 programming that inverted the program's control flow compared to MS-DOS.
Windows manage the I/O devices and calls program's event handler when the user performs some input.
While in MS-DOS the program in the main loop had to pools the I/O devices to know the position of the mouse and the status of the keyboard.
IoC pattern means event-driven instead of pooling the sources. The reference to sources of the events are passed to the program/object that will trigger its behavior when receives an event notification. The pattern apply to any kind of event.
IoC is often (mis)used as synonym for
DI or Dependency Injection and so with
IoC framework or
IoC container what is really intended is
DI framework.
DI pattern has two aspects:
- The 1st one refers to the object's interface that should define the services that the object requires, that are its dependencies and its collaborators, and also the services it provides. And distinguish between them. In C# as well as in Java a parametric constructor can be used to define the object dependencies&collaborators.
- The 2nd refers to the act often called "third-party binding" of passing the references of the required dependencies&collaborators to the object: this action must be taken externally, not by the objects itself or by its dependencies&collaborators.
The advantages of the design promoted by the
DI pattern are
- the clear distinction between an object's internal dependencies (that are defined in the parametric constructor without leaking into the public object interface) and its other peers (notification listeners, adjustments) that are defined in the public object interface (they can also be injected in the parametric constructor when needed) so that both internals and peers become visible clear and explicit. Therefore the behavior of the system can be easily understood
- the separation of the code that composes objects from the objects being composed, as suggested by the "composite simpler than the sum of its parts" principle
- the code that composes objects, that define the system structure, can be pushed up as far as possible; this enable aggressively refactoring of the compositional code to remove duplication and express intent, and thereby raise the abstraction level at which program so less and less code is needed to write more and more functionality as the system grows. For example it make it easy to run the same system in both the dev and test and production environment.
.
There are different opinions about the influence of
DI frameworks to the design of the system and the ability to encourage and support the use of the
DI pattern.
DI frameworks are almost unanimously recognized to be useful to dynamically load plug-ins into the running program and keep the technical implementation details clearly separated from the code in the application domain model and elsewhere in the system.
Some
DI framework uses XML files to configure the dependencies and the collaborators, this obfuscate the structure of the system and obstruct the refactoring of the system and the improvements of the system structure. This contrast the 2nd aspect of the
DI pattern.
Some
DI framework instead uses code to configure the dependencies and the collaborators, this is an improvement over XML. The auto-wiring and the configuration code make invisible in the program code the structure of the system. This does not totally support the 2nd aspect of the
DI pattern.
Some
DI framework uses reflection or similar low level techniques to poke internals (and eventually some peer) directly into an object's private fields, bypassing the constructor, adding complexity to client code. This add complexity to client code and make the behavior of the system harder to understand and change. This contrast the 1st aspect of the
DI pattern.
A suggestion is to initially avoid the use of the framework in the team, to understand learn the
DI pattern, and only later evaluate pro and cons of using a
DI framework: no framework or technique can survive inadequately trained developers.
Edit 9 Jan 2011, additional references:
Here a nice example of the the "composite simpler than the sum of its parts" principle:
-
http://blog.davidpeterson.co.uk/2011/01/object-oriented-example.html
See also
Is Dependency Injection like Facebook? by Steve Freeman.