Dependencies and Arrowheads

Dependencies burden your design

Fixing one bug often causes multiple new bugs. This article explains why by introducing some basics about dependencies. It also briefly introduces parts of UML to visualize these dependencies.

Problem

Fixing one bug may cause several new bugs.

Every programmer knows this problem: you fix one bug and three new bugs occur elsewhere which need to be fixed, too. This is a Code Smell called Shotgun Surgery. But why does this happen at all?

The answer lies in the dependencies structure of your classes. If you change one class, this change may affect all classes which are depending on your changed class. These affected classes may thus require further changes and affect further classes depending on them.

To solve this problem you need to keep the dependency structure of your software clean. But what exactly is the “dependency structure”?

From the example above, you can see that there is something like a “dependency flow” through your code. I want to introduce a way to visualize this flow: UML Diagrams.

UML

What is UML?

UML is short for Unified Modelling Language. It is a collection of different diagram types, to display all kinds of problems and solutions. These diagrams are standardized, widely accepted and used in the industry, especially in the sector of information technology.

UML Class Diagram Basics

The UML Class Diagram is especially useful to understand dependencies between your classes. So we need to introduce some basics.

In the following pictures we show how to display classes and their relationships in Class Diagrams. Take a look at the following pictures and their descriptions.

Classes are displayed as boxes with their name inside the box. The shown example visualizes a program that has two classes: Class A and Class B.

If Class A extends Class B, a line connects both classes which has a white triangular arrowhead at the base class. This is also known as A inherits from B or A is a subclass of B. All these expressions mean the same thing and all object-oriented languages offer this feature.

If Class A has a field of the type Class B it’s called an association from A to B. The association can be displayed by a solid line between the classes and an open arrowhead at the end of B.

If Class A has a method which makes use of Class B, we have a dependency from A to B. It’s displayed like the previous associations, but with a dashed line. Note that only this special relationship is called dependency when using the UML terms, while I call all the above relationships dependency in the scope of this article.

There are many more things you could display in a class diagram, but we don’t need more to understand how dependencies work.

The Arrowheads

All of the above relationships display an arrowhead pointing away from the depending class. This means changes to one class may affect exactly the classes pointing at it:

Changing class C, may cause changes in all red classes (D, E, F) but not in the blue classes (A, B).

The dependency flow

When you display your software in a class diagram now, you can follow the arrows backward to tell which class affects which other classes directly or indirectly:

Changing class C, may cause changes in all red classes (D, E, F, G, H) but not in the blue classes (A, B).

It’s not always trivial to prevent these indirect dependencies. The easiest approach is to keep the dependency-chains short, by inverting dependencies. But I will cover that in a future article.

Conclusion

You now have some basic understanding of why dependencies between classes cause problems and how to identify and visualize them using UML. We also explained why UML arrowheads point into specific directions.

 

Cheers,

Waog