In this episode, we tackle a higher form of the Spaghetti Code Anti-Pattern. While that is a code-level issue, the jumble antipattern shows up in the architecture. There are almost always going to be horizontal and vertical aspects of a design. Some facets are specific to the solution while others are common across multiple applications. When we confuse and tightly couple these aspects then it turns into a jumble
Defining the Jumble AntiPattern
The C2 wiki makes another appearance as we look into a definition for this anti-pattern. [Click Here to See The Page]
“”When horizontal and vertical design elements are intermixed, an unstable architecture results. Vertical design elements are dependent upon the individual application and specific software implementations. Horizontal design elements are those that are common across applications and specific implementations.“
The idea of vertical and horizontal components to a solution may seem like an academic discussion. However, it is essential to be able to differentiate among them. When you ignore that differentiation then you effectively remove your ability to re-use code.
A good example is a simple validation class. If you mix in the domain (application) specific functions with the general purpose ones then it becomes difficult to separate them. That leads to a struggle when trying to re-use that code in another domain.
I Need A Map
One of the benefits of well-considered design (AKA not a jumble) is that others can easily find features they are seeking. The less tested code that is domain specific will be in one place. On the other hand, the higher quality re-used code will be elsewhere. You then have a solution where the higher quality code is not going to get in your way while debugging. Better yet, you will be able to easily pull out the code that can be re-used.
Intentional Implementation
The best way to avoid the jumble antipattern is to spend time on design. This is a situation much like the idea “a place for everything and everything in its place.” When you are creating a method, function, or class then start by considering its aspect. Is this specific to the current application or something you can re-use? If it is likely to be re-usable then group it in with the other re-usable code. Do not make it hard on the next developer to figure out what code has re-use potential.
