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.

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.

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.

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.