Development AntiPattern: The Blob
- Symptoms
- Single class with many attributes & operations
- Controller class with simple, data-object classes.
- Lack of OO design.
- A migrated legacy design
- Consequences
- Lost OO advantage
- Too complex to reuse or test.
- Expensive to load
Notes:
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. [Akroyd 96]
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.
A lack of OO design. A program main loop inside The Blob class associated with relatively passive data objects. The single controller class often nearly encapsulates the applications entire functionality much like a procedural main program.
A migrated legacy design which has not been properly refactored into an OO architecture.
· The Blob compromises the inherent advantages of an OO design. For example, The Blob limits the ability to modify the system without
affecting the functionality of other encapsulated objects. Modifications to The Blob affect the extensive software within The Blob's
encapsulation. Modifications to other objects in the system are also likely to have impacts on The Blob's software.
· The Blob Class is typically too complex for reuse and testing. It is may be inefficient or introduce excessive complexity to reuse The
Blob for subsets of its functionality.
· The Blob Class may be expensive to load into memory, using excessive resources, even for simple operations.
Lack of an object-oriented architecture. The designers may not have an adequate understanding of object-oriented principles. Alternatively, the
team may be lacking appropriate abstraction skills.
Lack of (any) architecture. The lack of definition of the system components, their interactions and the specific use of the selected programming
languages. This allows programs to evolve in ad-hoc way due to the programming languages being used outside of their intended purposes.
Lack of architecture enforcement. Sometimes this AntiPattern grows accidentally, even after a reasonable architecture was planned. This may
be the result of inadequate architectural review as development takes place. This is especially prevalent with development teams new to OO.
In iterative projects, developers tend to add little pieces of functionality to an existing working classes, rather than add new classes, or revise the
class hierarchy for more effective allocation of responsibilities.
Specified Disaster. Sometimes The Blob results from the way requirements are specified. If the requirements dictate a procedural solution, then
architectural commitments may be made during requirements analysis which are difficult to change. Defining system architecture as part of
requirements analysis is usually inappropriate, and often leads to The Blob AntiPatterns, or worse.
As with most of the AntiPatterns in this section, the solution involves a form of re-factoring. The key is to move behavior from away from The Blob. It
may be appropriate to reallocate behavior to some of the encapsulated data objects in a way that make these objects more capable and the Blob less
complex. The method for refactoring of responsibilities is described as follows: