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?
If an entity is composed, is it still a god object?
object oriented;anti patterns;composition
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.  