ComposeGroup, ComposeRoot & ComposeItem

Each conceptual item the composition design pattern is a simple node to which additional functionality classes get added (i.e. 'Traits').

Composure has three core classes to represent these nodes:

• ComposeGroup: This is the class you'll use to represent the majority of the objects in your application. Traits will be added to these items to give them visuals and behaviours, although this needn't only represent visual objects (you could, for example, represent your physics engine as a ComposeGroup, with traits added to it to create gravity/wind/etc). More ComposeGroup items can then be added to this item, which will allow access between their traits).
• ComposeRoot: This forms the root of your application, all other items must be added to this item or one of it's decendants, this organises your application into a conceptual hierarchy. This hierarchy shouldn't be thought of necessarily as a visual heirarchy, more of as a grouping system. Note that the ComposeRoot class is just a subclassed ComposeGroup class that references itself as the root.
• ComposeItem: This class is the superclass of the ComposeGroup class and doesn't allow for the adding of children, as such it will rarely get used. In some systems, where performance is critical, representing certain numerous simple items (bullets for example) as ComposeItems will reduce the memory footprint and increase performance.

Overriding ComposeGroup & Prefabs

Normally, it's recommended not to override ComposeGroup ever. All the logic of your application items should exist within descreet, interchangable Traits.

The exception to this is the case of Prefabs, these are game items which have a preconfigured list of Traits. This can be a convenient way of spawning heaps of similar items quickly or creating preconfigured items for use by other developers. For example:

	class Bullet extends ComposeItem
	{
	
		public function new() 
		{
			super();
			addTrait(new ImageTrait("bullet.png"));
			addTrait(new RigidBody2D());
			addTrait(new Position());
			addTrait(new Health(1000));
		}
		
	}

Some Tips

• However irresistible, try not to represent numerous conceptual items as Traits added to a common ComposeGroup. If there are too many of them to bother creating ComposeGroups/ComposeItems individually, then it's probably best that they all reside within a single Trait (a particle engine, for example).
• Don't add Traits directly to your ComposeRoot item. Creating a stage:ComposeGroup item which is then added to your root could save you time later if you're required to wrap your app in a shell or have it run alongside another composition app.