Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 89 posts at DZone. You can read more from them at their website. View Full User Profile

Dependency Antipatterns – God Node

03.22.2013
| 6949 views |
  • submit to reddit

I wrote before about the dependency analysis and visualization tool Degraph. When you use such a tool to examine various projects you will find some patterns that stick out like a sore thumb. This is a first articles about  such antipatterns, including my interpretation of what is going wrong and how to fix it.

I’m using the somewhat abstract term node, which might refer to a class, a package or even to a slice that you define, bundling classes according to some rule that you see fit. If you are confused by the terminology you might have a look at the wiki page for Degraph, where I try to explain these terms.

God Node

When you see a node in a dependency diagram that has tons of in and outgoing connections, you are looking at the death rays emitting from a god node. It does a lot of important things, that’s why it depends on many other nodes. It also gets used by many things, which makes it even worse.

godObject

You want to extract stuff from that node! Why? Because when it does so many things and depends on so many things, it is very likely you

  1. can’t properly test it
  2. have to change it very often
  3. thereby over and over creating new bugs, that go undetected by your automatic tests.

If this is a simple node, i.e. it doesn’t represent at least a package or a class with inner classes, may the god class have mercy with your soul. Do some refactoring of that monster, until you can extract some classes. Prefer to extract classes that encapsulate some of the dependencies to other class. This image show how this looks like with the a new class represented by an orange octagon.

godObjectDelegate

An alternative start is to extract interfaces and make other parts of the application depend only on the interfaces. This will move remove some dependencies from the God Node and spread them among the new interface nodes, as sketched in the following image, with the introduced interfaces represented by orange octagons.

godObjectInterfaces

Note that

  1. Since the god node ‘implements’ the interface nodes it depends on them, not the other way round
  2. Some third node has to inject the implementation (the god node) into the clients so it will have dependencies to both. This is basically what I described in an earlier article about how to break dependency cycles.

If this is a compound node have a look inside. Often it already exhibits a structure of it own. Look at the upcoming posts about Dependency Antipatterns for stuff to look out for.

 

Published at DZone with permission of Jens Schauder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Luca Cavagnoli replied on Fri, 2013/03/22 - 3:12am

It seems more like quantitative analysis than qualitative analysis though.

It's interesting, but I'd take it with graind of sault.

Raging Infernoz replied on Sat, 2013/03/30 - 1:34pm

For Java, this is a pretty good example of why Maven is so valuable, and why Ant should be deprecated ASAP to the Apache Attic, to encourage people to migrate off that creaking old tool.

You can have a super pom project, which you can make the monolithic project a module of, refactor it apart into smaller module projects; you don't even have to split functionality into separate packages, just split the functionality into separate classes in other module projects. When the module projects are fine grained enough, you can change the client Maven projects to only reference dependencies for the smaller modules you actually need to use.

I've also used this approach to provide custom versions of libraries by using the shade plugin to replace some classes, so that I didn't have the hassle of having to do a project source branch to do this.  I've used this approach to provide customised libraries for public Maven plugins.

It would not surprise me at all, if the JRE, SDK, and JME is, or will be, built by Maven using the above approach.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.