9.4: Split Up God Class

Also Known As: The Blob [BMMM98], God Class [Rie96].

Intent Split up a class with too many responsibilities into a number of smaller, cohesive classes.

Problems

How do you maintain a class that assumes too many responsibilities?

This problem is difficult because:

• By assuming too many responsibilities, a god class monopolizes control of an application. Evolution of the application is difficult because nearly every change touches this class, and affects multiple responsibilities.

• It is difficult to understand the different abstractions that are intermixed in a god class. Most of the data of the multiple abstractions are accessed from different places.

• Identifying where to change a feature without impacting the other functionality or other objects in the system is difficult. Moreover, changes in other objects are likely to impact the god class, thus hampering the evolution of the system.

• It is nearly impossible to change a part of the behavior of a god class in a black-box way.

Yet, solving this problem is feasible because:

• You don’t have to fix the problem in one shot.
• You can use Semantic Wrapper to wrap it and present interfaces.

Solution

Incrementally redistribute the responsibilities of the god class either to its collaborating classes or to new classes that are pulled out the god class. When there is nothing left of the god class but a facade, remove or deprecate the facade.

Detection

A god class may be recognized in various ways:

• a single huge class treats many other classes as data structures.

• a “root” class or other huge class has a name containing words like “System”, “Subsystem”, “Manager”, “Driver”, or “Controller”.

• changes to the system always result in changes to the same class.

• changes to the class are extremely difficult because you cannot identify which parts of the class they affect.

• reusing the class is nearly impossible because it covers too many design concerns.

• the class is a domain class holding the majority of attributes and methods of a system or subsystem. (Note that the threshold is not absolute because some UI frameworks produce big classes with lots of methods, and some database interface classes may need a lot of attributes).

• the class has an unrelated set of methods working on separated instance variables. The cohesiveness of the class is usually low.

• the class requires long compile times, even for small modifications.

• the class is difficult to test due to the many responsibilities it assumes.

• the class uses a lot of memory.

• people tell you: “This is the heart of the system”.

• when you ask for the responsibility of a god class you get various, long and unclear answers.

• god classes are the nightmare of maintainers, so ask what classes are huge and difficult to maintain. Ask what is the class they would not like to work on. (Variant: Ask people to choose which class they want to work on. The one that everybody avoids may be a god class.)

Steps

The solution relies on incrementally moving behavior away from the god class. During this process, data containers will become more object-like by acquiring the functionality that the god class was performing on their data. Some new classes will also be extracted from the god class.

Figure \(\PageIndex{1}\): A god class is refactored in two stages, first by redistributing responsibilities to data containers, or by spawning off new classes, until there is nothing left but a facade, and second by removing the facade.

The following steps describe how this process ideally works. Note, however, that god classes can vary greatly in terms of their internal structure, so different techniques may be used to implement the transformation steps. Furthermore, it should be clear that a god class cannot be cured in one shot, so a safe way to proceed is to first transform a god class into a lightweight god class, then into a Facade that delegates behavior to its acquaintances. Finally, clients are redirected to the refactored data containers and the other new objects, and the Facade can be removed. The process is illustrated in Figure \(\PageIndex{1}\).

The following steps are applied iteratively. Be sure to apply Regression Test After Every Change:

1. Identify cohesive subsets of instance variables of the god class, and convert them to external data containers. Change the initialization methods of the god class to refer to instances of the new data containers.
2. Identify all classes used as data containers by the god class (including those created in step 1) and apply Move Behavior Close to Data to promote the data containers into service providers. The original methods of the god class will simply delegate behavior to the moved methods.
3. After iteratively applying steps 1 and 2, there will be nothing left of the god class except a facade with a big initialization method. Shift the responsibility for initialization to a separate class, so only a pure facade is left. Iteratively redirect clients to the objects for which the former god class is now a facade, and either deprecate the facade (see Deprecate Obsolete Interfaces), or simply remove it.

Tradeoffs

Pros

• Application control is no longer centralized in a single monolithic entity but distributed amongst entities that each assume a well-defined set of responsibilities. The design evolves from a procedural design towards an object-oriented design based on autonomous interacting objects.

• Parts of the original god class are easier to understand and to maintain.

• Parts of the original god class are more stable because they deal with less issues.

• Overall compilation time may be reduced due to the simplification of system dependencies.

Cons

• Splitting up a god class is a long, slow and tedious process.

• Maintainers will no longer beable to go to a single god class to locate behavior to fix.

• The number of classes will increase.

Difficulties

• God class methods may themselves be large, procedural abstractions with too many responsibilities. Such methods may need to be decomposed before cohesive sets of instance variables and methods can be teased out as classes.

When the legacy solution is the solution

What is riskier? To Split Up God Class or to leave it alone? A real god class is a large, unwieldy beast. Splitting it up into more robust abstractions may introduce considerable cost.

The key issue is whether the god class needs to be maintained. If the god class consists of stable, legacy code that rarely needs to be extended or modified, then refactoring it is a questionable investment of effort.

Suppose, on the other hand, that it is the clients of the god class that are unstable, and need to be frequently adapted to changing requirements. Then the clients should be shielded from the god class since it is not presenting a clean interface. Consider instead applying Present the Right Interface, which will introduce a layer of clean, object-oriented abstractions between the clients and the god class, and may make it easier to evolve the clients.

Rationale

Do not create god classes/objects in your system.

— Arthur Riel, Heuristic 3.2 [Rie96]

God classes impede evolution because they achieve only a low level of procedural abstraction, so changes may affect many parts of the god class, its data containers and its clients. By splitting a god class up into object-oriented abstractions, changes will tend to be more localized, therefore easier to implement.

Related Patterns

Foote and Yoder in “Big Ball of Mud” [FY00] note that god classes (and worse) arise naturally in software development.

“People build BIG BALLS OF MUD because they work. In many domains, they are the only things that have been shown to work. Indeed, they work where loftier approaches have yet to demonstrate that they can compete.

It is not our purpose to condemn BIG BALLS OF MUD. Casual architecture is natural during the early stages of a system’s evolution. The reader must surely suspect, however, that our hope is that we can aspire to do better. By recognizing the forces and pressures that lead to architectural malaise, and how and when they might be confronted, we hope to set the stage for the emergence of truly durable artifacts that can put architects in dominant positions for years to come. The key is to ensure that the system, its programmers, and, indeed the entire organization, learn about the domain, and the architectural opportunities looming within it, as the system grows and matures.”

— Foote & Yoder [FY00]

Present the Right Interface is a competing pattern that should be applied when the god class itself rarely needs to be modified or extended.