The component behavioral pattern allows you to add just the features to your objects that are needed and keep the features independent of each other.

The episode describes an example of how best to deal with an adventure game hero class. Instead of trying to make a particular game class, such as the hero, directly handle all the code needed to process input, detect collisions, update locations, and render images, a better solution is to put each of these operation into their own class.

The first step then is to separate these functional parts, or features, or domains, into their own classes. To bring the behavior back into the hero class, you could try to use inheritance but this leads to a rigid solution that’s defined at compile time. this episode explains how to accomplish this with components that are contained within the hero class. by doing this, the hero class becomes more generic and this same pattern can then apply to any game object.

When you decide to use composition to handle the various features, you’ll need to decide how the components will communicate with each other. One of the big goals of this design pattern is to keep the components independent of each other. How do you keep them independent but still allow communication?

You can use the game object class to mediate between the components. Either directly by storing the result of one component so it can be used by another component or by managing messages that can be sent from one component through the game object class and then to all the other components. The messaging approach is much more complicated and may not always be needed. Or maybe you can choose multiple solutions and have some components behaving one or multiple ways. common attributes that all game objects share can be updated directly. While less common attributes might be a good chance to use messages.


What's on your mind?
On a scale of 0 to 10, how likely are you to refer us to friends?