Dependency Antipatterns – Clotheslines

clothesLines

This is the third part in my little series about dependency anti-patterns. The first part was about the God Node, the second one about the Bypass

Images and nomenclature are based on Degraph.

When you have two slices with lots of parallel connections as in the image on the side, you found this patterns. Just as with real clotheslines there might be some crossing in the lines, but the majority is parallel.

This kind of stuff happens when you split classes into packages (or larger slices) not by the domain they deal with, but by the pattern they implement. An example would be a set of entities and there matching DAOs. If you put all the entities in one package and all the DAOs in another you get exactly this pattern. It is an example of high coupling and low coehesion and in case you are wondering: Yes we normally strive for the opposite.

You want to avoid clotheslines because the affected nodes are couple so tightly together that you can’t really split them, so you might as well throw them in one bag. Which in turn might result in a giant node, you you don’t want either.

The good news is the situation is easy to improve. Just arrange the classes connected by clothesline into one package. Possibly on their own, and if they have cross connections with other pairs, together with those. You’ll end up with something that looks more like the image below: More dependencies inside a package, fewer between packages. Also known as high cohesion, low coupling.

clothesLinesFixed

Java Application Architecture

At Devoxx last year I attended half a session by Kirk Knoernschild. I don’t know why I missed half the session, but I fixed that by listening to the full talk over at parleys (not sure if you can see the full talk with out registering).

I found the talk intriguing for two reasons. First Kirk looks so much like me that I think I’m seeing me when ever I see a picture of him. It is really unnerving. The other, more important one: He is arguing a similar point as I am.

One of his main messages is: As a responsible developer or an architect you must take care of modules and their dependencies.

While my point is: you should take care of packages and their dependency structure.

So I went and bought his book “Java Application Architecture” in order to learn more about what he has to say.

Java Application Architecture by Kirk Knoernschild

It turned out to be a book that every advanced developer or architect should read. A label that I haven’t attached to a book for quite some time. Why?

It covers the benefits and costs of a modular software architecture in great detail, something that I haven’t seen in another book. Other books describe how to write code on a very granular level, like methods, classes and patterns. Or they describe the large scale structures relevant in system architecture, but the middle ground of packages and modules gets ignored by most books I have seen so far.

After the general analysis of the effects of modularity, the middle part describes patterns of module dependencies. I personally found this part a little boring and repetitive, because I apply these kind of pattern for quite some time now. But I think it would be very helpful for others who want to apply the tool of modularization to their application.

In the last part Kirk describes how OSGI helps in achieving modularity and reaping the benefits of it. I found this part interesting again, because so far I’ve experienced OSGI only as a road block to productivity and this part together with the rest of the book explained how it actually could have helped me.

Of course the book isn’t perfect either. I think it is to repetitive, which made me skip some passages. Also the title is a little misleading, since it talks only about a very specific part of application architecture. But none of this should keep anybody from buying and reading this book.

Posted in: The Rest by Jens Schauder 6 Comments , , , ,

Dependency Antipatterns – The Bypass

This is the second part in my little series about dependency anti-patterns. The first part was about the God Node. Images and nomenclature are based on Degraph.

As long as the affected nodes are collapsed the Bypass looks just like any circular dependency.

bypassCollapsed

But if you expand them something strange happens. In one node (A) (the main road so to say) one part of the subnodes gets pushed to the left (A1), while the rest gets pushed to the right (A2). The A1 nodes depend on B (the actual bypass) and B depends on A2. Since all arrows still go from left to right it can get hard to spot the problem, when more nodes are involved.

bypassExploded

I have seen this many times when someone attempted some kind of dependency injection, but didn’t complete it. Maybe B is a plugin like class implementing a feature for an application A. For this it implements some kind of plugin interface A2, so that A doesn’t actually need to know B. But something (A1) has to plug everything together, so it has to know A1 and B. That is ok, it just shouldn’t be in the same node as A2.

Which already gives a fix to this kind of problem: Move A1 (or A2) to its own node, basically splitting A in two pieces, voila you just got rid of a circular dependency. An alternative is to move A2 into B. The correct decision depends on the semantics of the nodes involved.