3.5 The God Class Problem (Data Form)

The second form of the god class problem occurs very often when a designer is migrating a legacy system to a new object-oriented design. There is an enormous interest in finding a good process for this migration, since it is rare that a software developer gets to design a new system from the beginning. The legacy system is often fraught with many existing problems which need to be addressed. While examining a development process for migrating legacy systems is outside the scope of this text, it is within our interest to examine one of the problems such a process must address.

The high-level design shown in Figure 3.10 was taken from a legacy system that dealt with telephone call processing. The topology of this system consisted of a large global data structure, which I will call the CallProcessingBlock , and a number of call processing functions. The data structure contained all of the data that the many call processing functions need in order to fulfill their requirements. Each of the call processing functions used the data it needed directly from the global data structure. (The names of the individual data members and call processing functions is left abstract so as not to convolute the example.)

Figure 3.10. A legacy call processing system.

When the design team decided to migrate this system, they first encapsulated the CallProcessingBlock in a class and added accessor methods for each of the data members to the public interface of this new class (see Figure 3.11). The functions were then grouped together into controller classes. The controller classes would then use the accessor methods of the CallProcessing class to collect the necessary data. While such a system is certainly an improved migration from the original, it is not a good object-oriented design. The CallProcessing class is a god class that holds all of the data, while the controller classes violate the rule of keeping data and its behavior together. I would argue that controller classes are popular because it makes it seemingly easy to migrate legacy systems which possess this topology. The correct migration is to split the CallProcessingBlock into pieces based on collections of the call processing functions (see Figure 3.12). The collections of call processing functions and their portion of the data are grouped together based on the subset of the CallProcessingBlock data used. This leads to an object-oriented design that possesses the qualities of decentralization and bidirectionally related data and behavior.

Figure 3.11. A poor migration for the call processing system.

Figure 3.12. A better migration for the call processing system.