When I find a concrete dependency inside an extension method, I have been attempting to remove the (concrete) dependency by parameterising it like so
// original implementation
public static List<Address> GetDuplicate(this Address address)
{
var repository = new AddressRepository();
return repository.FindAddress(address.Street, address.Town);
}
// 'Fixed' implementation using 'parameter injection'
public static List<Address> GetDuplicate(this Address address, IAddressRepository repository = null)
{
repository = repository ?? new AddressRepository();
return repository.FindAddress(address.Street, address.Town);
}
My idea was that this would invert control of the collaborating class, AddressRepository, by making sure it could be passed in by the code using the method.
Anyway when a colleague saw this they said that the code still relied on a concrete implementation and was not using IOC. Although I can see there are some downsides of the code, I’m not sure I agree that it isn’t Inversion of Control since
- The code depends on an abstraction (IAddressRepository)
- Calling code can provide a different implementation.
What principle is violated with respect to IOC? Which part of the code in particular violates that principle? Simply put, is ‘parameter injection’ actually a thing?
5
…does the parameterisation of the dependency meet the requirements for “inversion of control”?
No. That’s just Dependency Injection.
Look very carefully at the Wikipedia definition for Inversion of Control:
Inversion of Control (IoC) describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library [or framework].
In traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the reusable code [the library or framework] that calls into the custom, or task-specific, code.
In other words, Inversion of Control is characterized by the Hollywood Principle: Don’t call us, we’ll call you.
I can think of at least two ways Inversion of Control can occur in everyday use. One way is by making use of the Subscriber Pattern. In event-driven UI’s, we don’t call the UI framework when a user clicks on a button. Rather, we subscribe to a Click event, and the UI framework calls us:
// Subscribe to Click event.
this.button1.Click += new System.EventHandler(this.button1_Click);
// Handler for click event
private void button1_Click(object sender, MyEventArgs e)
{
// Do something when user clicks button
}
Another example of Inversion of Control is sort methods that make use of a comparator to determine the behavior of the sort with different data types. The MSDN documentation for the Linq OrderBy method gives a good example of this.
First, we create a “comparer.” A comparer is a class that satisfies the IComparer interface:
public class IntegerComparer : IComparer<int>
{
public int Compare(int i1, int i2)
{
return i1 - i2;
}
}
Given an unsorted array of:
string[] unsortedArray = { "three", "six", "nine", "twelve", "fifteen", "eighteen" };
We can then use the comparer to sort the array by the number of characters in each string:
sortedArray = unsortedArray.OrderBy(a => a.Length, new IntegerComparer());
which yields the result:
six
nine
three
twelve
fifteen
eighteen
Once again, we have inverted control by relegating generic behavior to the framework, and having the framework call your custom code to get specific behavior.
Further Reading
Inversion of Control (Martin Fowler’s Bliki)
6