DI and IoC: pattern and frameworks, strengths and weaknesses

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.

Those notes are collected from these posts by Nat Pryce here and here and the Growing object oriented software group.

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.

Print | posted @ giovedì 6 gennaio 2011 21:41

Comments have been closed on this topic.