After working on the first iteration of my engine for about three years, I had more or less relied on inheritance to extend the object hierarchy and implement new functionality. For instance, to add a skybox to the engine I would need to create a subclass of the Entity3D class which forced it's position to be centered on the current camera location and render a cube surrounding the entire environment. This worked OK, but ended up with many, many different classes in a given scene graph for an application. There is also the issue of overloading a function from the original Entity3D class that shouldn't be completely replaced - such as an update function that writes the current local and world matrices for a given entity. Controllers Are BetterTo help in this situation, controllers can be used to implement special behavior without modifying or extending the Entity3D class. However, with controllers it can become tedious to communicate between the application, the entity, the controllers on an entity and how the rest of the entities on the scene graph talk to each other. Clearly there must be something better out there... Aggregates Are Even BetterI am now in the process of switching to using 'macro' objects which aggregate the entity object, it's controllers, and additional special state information for new style objects. The distinction seems to be subtle, but this design solves quite a few issues and makes using the rendering capabilities of the entity system very diversified.
In fact, this small change in design has allowed me to implement the full blown 3D UI with my existing rendering system without any special case code and still allowing for an object oriented approach of creating UI components. This will look alot better once I can take some screen shots, but it is going to be worth the extra effort to change things over. Definitely more to come soon!
http://gamearchitect.net/2008/06/01/an-anatomy-of-despair-aggregation-over-inheritance/