One of the difficult things with design principles like Inversion of Control, is that virtual all descriptions are lengthy and therefore difficult to grasp.
I’ve been using interfaces to decouple software for a long time, but it also took me a while to get IoC, especially the Inversion part.
The first time I got the Inversion principle was when reading the answer by Derek Greer to What is the Dependency Inversion Principle and why is it important? and especially the summary in the comment by Patrick McElhaney:
The difference between MyService → [ILogger ⇐ Logger] and [MyService → IMyServiceLogger] ⇐ Logger is subtle but important.
A similar explanation can be found in the somewhat longer, but very well written articles Dependency Injection Is NOT The Same As The Dependency Inversion Principle and A curry of Dependency Inversion Principle (DIP), Inversion of Control (IoC), Dependency Injection (DI) and IoC Container.
The whole point of the “Inversion” part is twofold:
- you declare the interface (ILogger) between a service user (MyService) and a provider (Logger) close to the user.
- you do this so that MyService does not need to change when you switch to a different provider: a new Logger provider needs to implement the ILogger interface too, even if it is from a completely different source or vendor.
Keeping that interface stable has the consequence that there will be more work on the provider side, for instance by using the adapter pattern to map the provider to the interface.
Knowing this, it was far easier to understand these articles that are often regarded as the fundamental ones, most from Martin Fowler’s site:
- Inversion of Control Containers and the Dependency Injection pattern.
- InversionOfControl.
- DIP in the Wild.
- IoC Types – PicoContainer – Codehaus.
–jeroen
The Wiert Corner - irregular stream of stuff 