Skip to main content
All CollectionsTutorials
How to get rid of cyclic dependencies with the help of Softagram Desktop
How to get rid of cyclic dependencies with the help of Softagram Desktop

Shows the steps to decrease the technical debt by removing cyclic dependencies based on Softagram proposal

Ville Laitila avatar
Written by Ville Laitila
Updated over 6 years ago

Cyclic dependencies creates technical debt by creating complexity. With Softagram you can refactor your code with proposals how to change the cyclic dependencies from your software. These proposals are made with algorithm that would create fully acyclic model. Note that you naturally should consider the proposed changes one by one, if it make sense to swap the proposed dependencies between the elements.

First directly to steps to use the funcitonality: 

  1. From Tools->Improve Code and Architecture->Simplify Dependencies, select "Propose Dependency Changes in Current view"

  2. Softagram shows in yellow color what kind of and how many changes needs to be done. Animated gif below:

Example and bacground for dependency related technical debt

Sometimes developers maximize re-use and forget to keep the design good. It may lead to difficult situation with two way dependencies and cycles. It naturally makes the software more difficult to change in the future, and also complicates unit testing.

In practise, the symptoms are that there are not many interfaces used, the state is shared between classes, data is exchanged between classes via static members and getter/setters.

Also, when doing procedural coding and forgetting the functional paradigm, the design easily gets skewed and difficult to maintain. Mostly this is seen as a huge amount of dependency cycles.

Example case, Netflix blitz4J project

This blitz4j case shows that the project suffers from a design that makes it rather static. Every unwanted dependency is related to accessing static members. It seems to be using Singleton pattern for two central classes. This pattern often breaks the good design and makes testing more difficult. See the situation from screenshot below:

Softagram proposes to change the direction of three dependencies.  These three dependencies go against the good layering that is otherwise well designed in this project. See the picture below with proposed (in yellow) changes:

Usually dependency injection or using parameters (and functional programming style) would prevent this kind of problem. Afterwards it might be very difficult or impossible to fix, so this supports the fact that Softagram should be used in the project from the very beginning.

Did this answer your question?