Enterprise Integration Zone is brought to you in partnership with:

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 85 posts at DZone. You can read more from them at their website. View Full User Profile

Dependency Antipatterns – The Bypass

03.27.2013
| 5074 views |
  • submit to reddit

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.

 

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.)