Wednesday, 11 March 2015

Dependency Elimination Principle

This is the third, and final part of my series on abstractions.

I've wrote about what good dependencies are before, and the benefits if you can limit and remove them where possible.

You can take this idea further though, by applying concepts from functional programming such as "depend on values rather than dependencies".

A wise colleague started me down this path of passing values, rather than dependencies on collaborators after we repeatedly found ourselves depending on implementation details. This meant our high level domain logic was tightly coupled to low level implementation details.

Brian Geihsler reminded me of this concept with an excellent demonstration of this in practice and has allowed me to put a name to this practice.

Additionally J.B. Rainsberger's example is with a virtual clock, another common dependency we often need. In this case, ask for the time, not how you get the time. The example also highlights another common problem with conventions when using a framework or library.

Here we can handle commands but only those that match the signature of taking a single command, and returning no response. In order to apply the Dependency Elimination Principle (DEP) and remove the clock wrapper we can introduce an overload. Our tests will be expressed using the overload, while the production code will make use of the standard method. If the class in question has a relevant set of interfaces, the overload would be omitted from this to ensure that consumers have a clean, focused API to consume.

When the DEP is applied to other dependencies such as configuration details, flexibility is achieved by the ability to provide these values from any source. As a side effect, coupling has been reduced, while also removing an unnecessary abstraction from the codebase.

Try to apply the DEP where possible. Remove as many dependencies as possible for flexible, maintainable code. Not all dependencies can be eliminated, but unless the dependency is a valid abstraction it may be worth considering removing or reducing use.


  1. Looks good, but in your last Handle() function, I'd rename timeNow to asOf or asOfInstant, in order to emphasise that that function doesn't rely on what the instant of time means. Calling that parameter timeNow provides a good example of a leaky abstraction: an irrelevant detail creeps in only because of how *one client* intends to use the function.

    1. Thanks for the feedback.

      I mentioned in the gist (now updated) that a better name should be used. asOfInstant is pretty nice the more I think about it, especially given your second point about how a single client uses the method. Another client would be your tests, at which point timeNow may be future, past, present. Great point.