Component

Intent

Allow a single entity to span multiple domains without coupling the domains to each other.

The Pattern

Imagine we have a class that spans multiple domains. We could have a single class manage all of the complexity, or we could split each domain into its own class, and have our class just manage the components.

When to Use It

• You have a class that touches multiple domains which you want to keep decoupled from each other.

• A class is getting massive and hard to work with.

• You want to be able to define a variety of objects that share different capabilities, but using inheritance doesn’t let you pick the parts you want to reuse precisely enough.

Splitting out a Domain

class Bjorn {
public:
    Bjorn() : velocity_(0), x_(0), y_(0) {}
 
    void update(World& world, Graphics& graphics);
private:
    static const int WALK_ACCELERATION = 1;
 
    int velocity_;
    int x_;
    int y_;
    Volume volume_;
    Sprite spriteStand_;
    Sprite spriteWalkLeft_;
    Sprite spriteWalkRight_;
};

void Bjorn::update(World& world, Graphics& graphics) {
    switch (Controller::getJoystickDirection()) {
        case DIR_LEFT:
            velocity_ -= WALK_ACCELERATION;
            break;
        case DIR_RIGHT:
            velocity_ += WALK_ACCELERATION;
            break;
    }
 
    x_ += velocity_;
    world.resolveCollision(volume_, x_, y_, velocity_);
    Sprite* sprite = &spriteStand_;
    if (velocity < 0) sprite = &spriteWalkLeft_;
    else if (velocity_ > 0) sprite = &spriteWalkRight_;
 
    graphics.draw(*sprite, x_, y);
}

Splitting Out a Domain

class InputComponent {
public:
    void update(Bjorn& bjorn) {
        switch (Controller::getJoystickDirection()) {
            case DIR_LEFT:
                bjorn.velocity -= WALK_ACCELERATION;
                break;
            case DIR_RIGHT:
                bjorn.velocity += WALK_ACCELERATION;
                break;
        }
    }
private:
    static const int WALK_ACCELERATION = 1;
};

class Bjorn {
public:
    int velocity;
    int x;
    int y;
 
    void update(World& world, Graphics& graphics) {
        input_.update(*this);
 
        x += velocity;
        world.resolveCollision(volume_, x, y, velocity);
 
        Sprite* sprite = &spriteStand_;
        updateSprite(*sprite);
        graphics.draw(*sprite, bjorn.x, bjorn.y)
    }
private:
    void updateSprite(Sprite& sprite) {
        if (velocity < 0) sprite = &spriteWalkLeft_;
        else if (velocity > 0) sprite = &spriteWalkRight_;
    }
    InputComponent input_;
    Volume volume_;
 
    Sprite spriteStand_;
    Sprite SpriteWalkLeft_;
    Sprite spriteWalkRight_;
};

Let’s keep splitting:

class PhysicsComponent
{
public:
  void update(Bjorn& bjorn, World& world)
  {
    bjorn.x += bjorn.velocity;
    world.resolveCollision(volume_,
        bjorn.x, bjorn.y, bjorn.velocity);
  }
 
private:
  Volume volume_;
};

class GraphicsComponent
{
public:
  void update(Bjorn& bjorn, Graphics& graphics)
  {
    Sprite* sprite = &spriteStand_;
    if (bjorn.velocity < 0)
    {
      sprite = &spriteWalkLeft_;
    }
    else if (bjorn.velocity > 0)
    {
      sprite = &spriteWalkRight_;
    }
 
    graphics.draw(*sprite, bjorn.x, bjorn.y);
  }
 
private:
  Sprite spriteStand_;
  Sprite spriteWalkLeft_;
  Sprite spriteWalkRight_;
};

Here’s our Bjorn Class.

class Bjorn
{
public:
  int velocity;
  int x, y;
 
  void update(World& world, Graphics& graphics)
  {
    input_.update(*this);
    physics_.update(*this, world);
    graphics_.update(*this, graphics);
  }
 
private:
  InputComponent input_;
  PhysicsComponent physics_;
  GraphicsComponent graphics_;
};

Robo Bjorn

One more step, we can make this better by abstracting out the behavior to interfaces.

class InputComponent {
public:
    virtual ~Inputcomponent() {}
    virtual void update(Bjorn& bjorn) = 0;
};

Next, we have our current user input handling code conform to that interface:

class PlayerInputComponent: public InputComponent {
public:
  virtual void update(Bjorn& bjorn) {
    switch (Controller::getJoystickDirection()) {
      case DIR_LEFT:
        bjorn.velocity -= WALK_ACCELERATION;
        break;
 
      case DIR_RIGHT:
        bjorn.velocity += WALK_ACCELERATION;
        break;
    }
  }
 
private:
  static const int WALK_ACCELERATION = 1;
};

Now Bjorn should hold a pointer to that input component instead of having an inline instance:

class Bjorn {
public:
  int velocity;
  int x, y;
 
  Bjorn(InputComponent* input)
  : input_(input)
  {}
 
  void update(World& world, Graphics& graphics) {
    input_->update(*this);
    physics_.update(*this, world);
    graphics_.update(*this, graphics);
  }
 
private:
  InputComponent* input_;
  PhysicsComponent physics_;
  GraphicsComponent graphics_;
};

Now, when we instantiate Bjorn, we pass in an input component for it.

Bjorn* bjorn = new Bjorn(new PlayerInputComponent());

We pay the cost of a virtual function call for our update() functions, but instead, we can swap out the InputComponent at will:

Let’s say we wanted an AI to control Bjorn, like on a Demo screen:

class DemoInputComponent: public InputComponent {
public:
    virtual void update(Bjorn& bjorn) {
        // Allow AI to control Bjorn
    }
};

Now we wire him up with our new component:

Bjorn* bjorn = new Bjorn(new DemoInputComponent());

No Bjorn at all?

Actually, Bjorn is just a component bag. Let’s go further with the physics and graphics and make them interfaces too.

class PhysicsComponent {
public:
  virtual ~PhysicsComponent() {}
  virtual void update(GameObject& obj, World& world) = 0;
};
 
class GraphicsComponent {
public:
  virtual ~GraphicsComponent() {}
  virtual void update(GameObject& obj, Graphics& graphics) = 0;
};

Rename Bjorn as GameObject:

class GameObject {
public:
  int velocity;
  int x, y;
 
  GameObject(InputComponent* input,
             PhysicsComponent* physics,
             GraphicsComponent* graphics)
  : input_(input),
    physics_(physics),
    graphics_(graphics)
  {}
 
  void update(World& world, Graphics& graphics) {
    input_->update(*this);
    physics_->update(*this, world);
    graphics_->update(*this, graphics);
  }
 
private:
  InputComponent* input_;
  PhysicsComponent* physics_;
  GraphicsComponent* graphics_;
};

class BjornPhysicsComponent : public PhysicsComponent {
public:
  virtual void update(GameObject& obj, World& world) {
    // Physics code...
  }
};
 
class BjornGraphicsComponent : public GraphicsComponent {
public:
  virtual void update(GameObject& obj, Graphics& graphics) {
    // Graphics code...
  }
};

And now we can build Bjorn again, without even having a dedicated class for him.

GameObject* createBjorn() {
  return new GameObject(new PlayerInputComponent(),
                        new BjornPhysicsComponent(),
                        new BjornGraphicsComponent());
}

How does the object get its components?

• If the object creates its own components:
  • The object itself ensures it has the components it needs.
  • It’s harder to reconfigure the object.
• If outside code provides the components:
  • The object becomes flexible
  • It can be decoupled from the concrete component types.

How do components communicate?

• By modifying the container object’s state.
• By referring directly to each other.
• By sending messages There’s no one right answer

Prev: type-object Next: event-queue