AntiPattern Name: The Blob
Also Known As: Winnebago and The God Class
Most Frequent Scale: Application
Refactored Solution Name: Refactoring of Responsibilities
Refactored Solution Type: Software
Root Causes: Sloth, Haste
Unbalanced Forces: Management of Functionality, Performance, Complexity
Anecdotal Evidence:
“This is the class that is really the heart of our architecture.”
Background
Do you remember the original black-and-white movie The Blob? Perhaps you saw only the recent remake. In either case, the story line was almost the same: A drip-sized, jellylike alien life form from outer space somehow makes it to Earth.
Whenever the jelly thing eats (usually unsuspecting earthlings), it grows. Meanwhile, incredulous earthlings panic and ignore the one crazy scientist who knows what’s happening. Many more people are eaten before they come to their senses. Eventually, the Blob grows so large that it threatens to wipe out the entire planet.
The movie is a good analogy for the Blob AntiPattern, which has been known to consume entire object-oriented architectures.
General Form
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.
In general, the Blob is a procedural design even though it may be represented using object notations and implemented in object-oriented languages. A procedural design separates process from data, whereas an object-oriented design merges process and data models, along with partitions.
The Blob contains the majority of the process, and the other objects contain the data. Architectures with the Blob have separated process from data; in
other words, they are procedural-style rather than object-oriented architectures.
The Blob can be the result of inappropriate requirements allocation. For example, the Blob may be a software module that is given responsibilities that overlap most other parts of the system for system control or system management.
The Blob is also frequently a result of iterative development where proof-of-concept code evolves over time into a prototype, and eventually, a production system. This is often exacerbated by the use of primarily GUI-centric programming languages, such as Visual Basic, that allow a simple form to evolve its functionality, and therefore purpose, during incremental development or prototyping.
The allocation of responsibilities is not repartitioned during system evolution, so that one module becomes predominant. The Blob is often accompanied by unnecessary code, making it hard to differentiate between the useful functionality of the Blob Class and no-longer-used code (see the Lava Flow AntiPattern).
Symptoms And Consequences
Single class with a large number of attributes, operations, or both. A class with 60 or more attributes and operations usually indicates the presence of the Blob
A disparate collection of unrelated attributes and operations encapsulated in a single class. An overall lack of cohesiveness of the attributes and operations is typical of the Blob.
A single controller class with associated simple, data-object classes.
An absence of object-oriented design. A program main loop inside the Blob class associated with relatively passive data objects.
(1 votes, average: 5.00 out of 5)