The posted code is a variant of a the composite pattern. This design pattern is structural pattern used to allow clients to treat individual objects and complex objects, such as those composed of multiple objects, in a uniform manner. For instance, a rendering loop can iterate over a collection of objects, calling draw()
on each of them. As this is a structural pattern, it is difficult to subjectively answer if this is instance of overengineering, as it would require examining more class hierarchies and architecture.
However, neither the class naming conventions of Component
and Composite
nor the use of the composite design pattern implies this is a "component-based" design. I was not familiar with the game programming component pattern, but it essentially appears to be the strategy pattern with state coupled within the algorithm class, resulting in a simplified interface between strategy
and context
. In either case, these two patterns are behavioral patterns that accomplish interchangeable and encapsulated algorithms. Therefore, the posted code does not implement a "component-based" design, as neither the Component
, Composite
, Entity
, nor Player
class provides a means to encapsulates the algorithms in an interchangeable manner. For example, Entity::update()
will always calculate the position in the same manner. This coupling requires the Entity
class hierarchy to be expanded if Entity
needs to use a different physics model (consider the case of an Entity
warping to a planet with a different set of physics), rather than delegating to a Physics
hierarchy of classes that encapsulate the algorithms.