While I was reading The Art of Unit Testing by Roy Osherove, I found references to topics that required more investigation. Inversion of Control or IoC was one of them. I vaguely remember reading about it somewhere but being a tech trainer of way too many technologies, and now a lab developer (basically quality assurance checking & screnshotting of MOC labs & labs from other companies), I've let some topics slide away in favor of stuff related to my job. It's part of the reason I started writing this blog, to hone my skillsets. And now, on to Inversion of Control:
Inversion of Control is based on the idea of flow control. When you start programming, you learn to write code in classes and methods that control the flow of the program. Your code calls methods that do something and answer back to your code. In Inversion of Control, your central classes wait for the phone call that tells them things they need to know to perform their own activities.
The example onWikipedia shows a serverFacade class that initially takes an object parameter to its respondToRequest method. The object is a request for data. The respondToRequest method then uses a DAO (Data Access Object) to get data via it's getData method and convert the data via the aspect's convertData method after using the businesslayer object to test if that object is valid. Based on the first implementation, the serverFacade object is coupled to the DAO object. In the lab of OOP, coupling is discourage. Since the serverFacade shouldn't know anything about how to convert data, or what to return if the data conversion fails (it is only a facade after all), the second implementation moves all the data conversion and return decisions to the DAO class. This in effect, decouples the two classes.
In Martin Fowler's article Inversion of Control Containers and the Dependency Injection pattern, he uses a simple class that splits out finding all movies to a finder class. Problems arise when his friends want that functionality for their programs. They might want to store movies in a different format or in a database. An interface or abstract class solves this by allowing the new developer to create a new class to pass to the MovieLister class that can find all of the movies in their own way via their own implementation.
The key points to both of these examples is that :
- The classes need to have very specific goals. If an activity doesn't correspond to the method or class, it needs to be moved out.
- In order to allow for different external dependencies like how the movies are stored and retrieved, create an interface or abstract class. (This idea makes your program easier to fit different situations as needed.)
Based on Fowler's explanation, what we're really talking about is setting up "plugins" for our software. Essentially you now have the ability to plugin any external movie storage into his MovieLister class. Data storage is only one of the types of external or outside dependencies your software could come across. It could also rely on network availability, configurations as well as configuration files or data stored on a network, or outside services.
Fowler asserts that Inversion of Control is a common characteristic of a framework. In Inversion of Control he says:
"A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points."
Fowler also thinks Inversion of Control Containers is too generic and renames this to Dependency Injection and further discusses the Server Locator pattern. I highly suggest you read his full article.
Going back to the Wikipedia article, it mentiosn that Inversion of Control is also known as the Hollywood Principle. Basically is the ""Don't call us, we'll call you." concept. IoC takes the integration and configuration of the system out of the application, and performs dependency injection.
Further Reading:
Design pattern – Inversion of control and Dependency injection
Design Better Software with the Inversion of Control Pattern
Inversion of Control Pattern