The alternative can be found by many names, though none are definitive yet. In this book, we will call it the Component Object Model, but others have called the Entity Component System or just Component System. No matter what you call it, the concept is surprisingly simple to learn and easy to implement.

The Component Object Model inverts the concept of the Decorator pattern, where each Decorator added a new layer on top of the game object. Instead of layering our object, which we have already seen problems with, we will put the decorations inside of it. Since we don't know how many we will need, our object will hold a container of decorations, as opposed to a single pointer. In the simplest form, our object is nothing more than a container for these components.

If you search for Component Object Model (or Component Based object Model) on the Internet, you will get results that are similar to what we saw in the Strategy pattern. The object contains hardcoded pointers to each possible strategy. While using this approach alone is much better than a monolithic object or an inheritance-based object, we are stuck checking for null pointers or constantly modifying what strategies exists in our object.

In this alternative method, every strategy type will derive from a common interface. This way, our object can contain an array, or in our case an STL vector of base class Component pointers. This is like the Decorator, except our object is a separate class; it doesn't derive from the Component interface. Instead, a Component will have a pointer to its parent object class. This solves the problem in which a Decorator didn't know whether it held a pointer to another Decorator, or to the actual object. Here we avoid that problem by always giving our Component a pointer to the object it controls:

//Using only Strategy Pattern 
class Object 
{ 
  public: 
    void Update(float dt);//Non virtual function to update 
       Strategies 
 //Other interface here 
 //... 
  private://Lots of different Strategies 
    GfxComp*   m_gfx; 
    BehaviorComp* m_behavior; 
    ColliderComp* m_collider; 
}; 
 
//Using Flexible Component Object Model 
class Object 
{ 
  public: 
    void Update(float dt);//Non virtual function to update 
       Components 
    //Other interface here 
 //... 
  private: 
    std::vector<Component*> m_components. 
}; 
 
//Our Base Component 
class Component 
{ 
  public: 
    virtual void Update(float dt) = 0; 
  protected: 
    Object* m_obj; 
};

This approach allows us to be very flexible because our object is nothing more than components. There is nothing in it that is specific to any type. There is no code that is strictly for the Player or SuperRaider. We are free to add, change, or remove anything at runtime. This is important because in the early stages of development, the game design and game objects will change a lot. If we were to hardcode pointers to different base class Strategies, we would spend a lot of time changing those pointer types in the game object.

Using the Component Object Model makes our code almost completely reusable as well. The game object itself is just an empty container of Components, and they are often so simple that most of them, such as a CircleCollider, can be used in any game. This means that a behavior component, originally meant only for the Player or SpawnerStation, can be easily used for any game object.