Bug Control ... Dependency Inversion Explained.

April 03, 2013

Let's start with a real world example that has nothing to do with software or code. Or, maybe it has everything to do with software and code. You decide. Let's proceed.

Imagine you are a business owner and that you are totally blind.  You can't see a lick. But like everyone else who owns a business, you rely on other companies to supply products and services that you need in order to deliver your service. 
Since you are blind, however, you can only read invoices if they are written in Braille. Because you can only read Braille, you hire an translator who can convert any invoice from any company to Braille, no matter what format the invoice comes in.
What happens if you get a new vendor who has an invoice format that your translator doesn't understand?
The answer is either you find another translator, or that vendor doesn't get paid. And if that vendor doesn't get paid, he'll stop supplying you. And if he stops supplying you, you can't deliver your service.
Stop here. Notice that it's you who depends upon someone else so that youcan respond to your invoices.
Now let's change the game so that you and your translator(s) don't have to work so hard.
What if you, as a powerful business owner, told all your vendors - "If you wish to do business with me, you will submit your invoices in Braille..."?
They don't want to lose your business, so they all gladly comply.
Don't look now, but what you've just done was to apply Robert C. Martin's (a.k.a. Uncle Bob's) Dependency Inversion Principle.
Since you did that, it no longer matters what format your vendor's like to send their invoice in - if they want to do business with you, they now knowthey have to send it in Braille!
Now let's put this into software development terms.
Unfortunately, there's a whole lot of software out there that seems to be perpetually buggy.  One of the most common themes among those buggy software packages is that they don't invert their dependencies.  

If Application A relies on Service 1, and Service 1 decides it needs to change in some major way, then chances are good that Application A is going to break.
When we're writing software, we should never make our high level modules (applications) depend on low level modules (services) themselves, and vice versa. 
Instead, applications should rely only on a promise of what it'll receive from a service and a service should only rely on a promise of how it needs to supply it's data, no matter who it is going to. 
If those promises are never broken, then it doesn't matter how they get fulfilled.
The blind man doesn't care if internally, his vendor starts an invoice in Spanish - because he knows that by the time he receives it, it'll be in Braille! 
Makes for an easier life for the blind business owner, eh?
That's just a cool way of saying the blind man (application) has less headaches (bugs).
Read more about Robert C. Martin's Dependency Inversion Principle.

Information and material in our blog posts are provided "as is" with no warranties either expressed or implied. Each post is an individual expression of our Sparkies. Should you identify any such content that is harmful, malicious, sensitive or unnecessary, please contact marketing@sparkhound.com.

Meet Sparkhound

Review our capabilities and services, meet the leadership team, see our valued partnerships, and read about the hardware we've earned.

Engage with us

Get in touch with any of our offices, or check out our open career positions and consider joining Sparkhound's dynamic team.