Composition

Well I've been bitten by the Composition bug. In a big way. So to satiate my newfound curiosity, I must confess I've been spending time on an experimental clone of my 2D engine using a technique of dynamic Composition.

The Composition version of the engine is based around a single "Game Object" class. This class is effectively nothing more than a collection of IAugmentation interfaces.

In my existing engine, the Sprite class has become quite large; what's more, not all Sprites always utilize every member and feature of the class. By partitioning this class into several different stand-alone "mini-classes" (all of which implement the IAugmentation interface), these mini-classes become "Augmentations". From this, one can start with an empty game object and build it into anything by adding the appropriate behavioral and/or data Augmentations to it's IAugmentation collection.

What's seductive about the Composition model is that this building process is not significantly different between design time and run time. To me this is the primary advantage of using Composition over Inheritance, which AFAIK is largely static at run time. I.e., once you define your class that inherits from <whatever>, you're stuck with that at run time. With Composition, you could simply remove one Augment and add another.

My only concern with what I've developed so far is that dictionary lookups are becoming somewhat frequent - i.e., I find myself querying whether or not a game object has been augmented with <augmentX>, and if so, retrieving that augment for use. These queries don't exist so much in the Inheritance model, and this aspect may require some fine-tuning as things get progressively more complex. But, we shall see.

Fun stuff!