The Blob Anti-Pattern

We will kick off the new season with a look at the Blob anti-pattern.  This is one that is common and easy to fall into.  The tendency to kick design decisions down the road is often a slippery slope that leads to a Blob.

Defining the Blob Anti-Pattern

I like the definition of a Blob found on the SourceMaking site. [Click Here to See The Page]

"The Blob is found in designs where one class monopolizes the processing, and other classes primarily encapsulate data. This AntiPattern is characterized by a class diagram composed of a single complex controller class surrounded by simple data classes. The key problem here is that the majority of the responsibilities are allocated to a single class."

You might also call this the One Ring pattern.  That would be from The Hobbit and the quote "one ring to rule them all."  It may seem like a good thing to have most of your code in one class.  However, do you think that is a proper object-oriented design?

Growing Out-Of-Control

The problem with a blog anti-pattern is that it grows as the application grows.  The class that started as one of the larger ones in the system becomes all-consuming.  At some point, the question of what is not a part of the Blob provides the answer "almost nothing."  This is hard to maintain and navigate as lacking security.  Therefore, a lot of the critical criteria for object-oriented design are not being met. 

A Technical "Junk Drawer"

In the physical world, we have ideas of storage closets and junk drawers.  In many cases, these containers are hard to navigate.  You also think an object might be in there.  However, you are afraid to look.  A Blob class is almost identical.  It is most likely that the method you are looking for is in the class.  On the other hand, it is probably kludgey and not something you want to touch.

This catch-all approach to methods often leads to duplicate code and fragile implementations.  It also feeds itself.  Thus, every new feature becomes easier to create from scratch in the class.  Compare that to tying together method calls across objects as normal OOP provides.