I am working on a system to configure hardware. Unfortunately, there is tons of variety in the hardware, which means there’s a wide variety of capabilities and configurations depending on what specific hardware the software connects to.
To deal with this, we’re using a Component Based Entity design where the “hardware” class itself is a very thin container for components that are composed at runtime based on what capabilities/configuration are available. This works great, and the design itself has worked well elsewhere (particularly in games).
The problem is that all this software does is configure the hardware. As such, almost all of the code is a component of the hardware instance. While the consumer only ever works against the strongly typed interfaces for the components, it could be argued that the class that represents an instance of the hardware is a God Object.
If you want to do anything to/with the hardware, you query an interface and work with it.
So, even if the components of an object are modular and decoupled well, is their container a God Object and the downsides associated with the anti-pattern?
According to the God Object wikipedia entry, “A god object is the object-oriented analogue of failing to use subroutines in procedural programming languages, or of using far too many global variables to store state information.” In other words, it’s a tightly coupled mess that’s been wrapped in an object.
According to you, the hardware class is “is a very thin container for components”. I don’t believe there’s any way for a very thin container to be a tightly coupled mess, unless it were tightly coupled to the components it contains. You describe the components as “composed at runtime based on what capabilities/configuration are available”, which implies that there are multiple possible components that could fit in a slot in the container, so your container must be decoupled from its components.
So, unless I’ve misunderstood your description, your hardware class is not a God Object. It might be very large at runtime, but I can’t see how being large at runtime could be a problem, as long as both the individual pieces and the ways of putting them together are not tightly coupled messes.
Where does the logic and complexity live? If the outermost Hardware instance is mainly a facade or adapter, while the sub-components have most of the logic and behavior, then I’d say “No”.
There may be other criticisms you could level at it, but to me a “God Object” is more often a class with way “too many” lines of code doing “too many” different kinds of things.