[ archives ]

Death Star

In the world of object-oriented programming, a God object knows too much or does too much. It is an example of an anti-pattern – or the programming equivalent of the Aquinian unmoved-mover.

Programming problems are broken down into several smaller problems (divide and conquer) and solutions are created for each of them. Once the small problems have been solved, the big problem as a whole has been solved. Therefore there is only one object about which an object needs to know everything: itself…

Likewise, there is only one set of problems an object needs to solve: its own.
God object–based code does not follow this approach. Instead, most of a program’s overall functionality is coded into a single “all-knowing” object, which maintains most of the information about the entire program and provides most of the methods for manipulating its data.

Because this object holds so much data and requires so many methods, its role in the program becomes God-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the God object for most of their information and interaction. Since the God object is referenced by so much of the other code, maintenance becomes more difficult than it would in a more evenly divided programming design.

So, while creating a God object is typically considered bad programming practice, this technique is occasionally used for tight programming environments (such as micro controllers and haptic applications), where the slight performance increase and centralization of control is more important than maintainability and programming elegance.

Read More