Edmund Kirwan

About Edmund Kirwan

Edmund is a programmer with a telecoms company in Stockholm where he is currently working on a large-scale network simulator. In his spare time he thinks far too much about program-structure.

Dependency inversion: the structure logarithm

Re-examining benefits.

Through the corroded dripping pipes of transitive dependencies, ripple effects gush. Programmers sometimes spend arduous days clambering down into the darkened building-tall labyrinths of plumbing for no other reason than to rip out some of those transitive dependencies so that predictability of cost of change might improve (amplification offering prime motivation). Those programmers that return often, after lengthy recuperation, babble of ancient principles glimpsed in new garb.

Consider the spoiklin diagram of figure 1, in which three methods – a(), b() and c() – call a utility method, d(), which in turn calls five others.
 

Figure 1: A simple system of nine methods.

Figure 1: A simple system of nine methods.

How many transitive dependencies appear in figure 1? This essentially asks how many ways we can fall from the top to the bottom row. From a() there is only one path, to d(), but from d() five possible choices exist. Method a() can reach the bottom in five ways:

  • a() → d() → e()
  • a() → d() → f()
  • a() → d() → g()
  • a() → d() → h()
  • a() → d() → i()

Thus there are five transitive dependencies reaching from a() and the same amounts from b() and c(), giving a total of 3 x 5 = 15. In general this configuration, where n elements depend ultimately on m elements, generates n x m transitive dependencies.

Now consider that the programmer wishes to further keep de-couple the three client methods from the implementation of the utility method, d(). To do so, the programmer unsheathes the glittering dependency inversion principle and slashes a new interface with an abstract d() method which a concrete class will then implement. Figure 2 shows the resulting system.

Figure 2: Dependency inversion.

Figure 2: Dependency inversion.

In figure 2, the same three methods – a(), b() and c() – call utility method d() below but now via the new interface. The concrete class implementing the utility method also has a d(), one on which no dependencies fall (clients invoke the interface method, not the concrete method) so that the concrete d() appears on the top row, a dashed-line showing its inheritance dependency on its corresponding interface method below.

How many transitive dependencies does figure 2 contain? All four methods on top terminate on the abstract d() below, yielding four transitive dependencies. Concrete method d() above also has five dependencies on the original bottom-row methods, bringing the total number of transitive dependencies to nine.

Note, however, that a fundamental structural change has taken place. The number of transitive dependencies can be now expressed as a sum rather than a product. That is, the original system generated 3 x 5 transitive dependencies; the new system generates 3 + 6 transitive dependencies. In general we can say that where n original elements depend ultimately on m original elements, the above dependency inversion will reduce the number of transitive dependencies from n x m to n + m + 1. If n and m are large, this can be a significant saving.

Just as mathematical logarithms help ease calculation burden by reducing a product to an addition, so too can the dependency inversion principle help reduce the number of transitive dependencies from a product to an addition. Furthermore, this application of the dependency inversion principle has also reduced the system’s depth, “depth” being the average length of the system’s transitive dependencies. In figure 1, all the transitive dependencies are of length three; in figure 2, they are all two elements long. Given that ripple effects cause most destruction when wormed deep in a vast profusions of transitive dependencies, the dependency inversion principle would seem a double benefactor.

Summary

Old crotchety principles sometimes surprise. The dependency inversion principle has long earned respect from programmers for its prowess at smashing the rigidity and fragility of otherwise un-lubricated systems. Yet this fails to map the full extent of its powers. Seen from a purely structural perspective, it can be used to reduce both the number and length of transitive dependencies squirming through a program.
 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


nine − = 8



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close