Type Objects

In our introductory lessons, we discussed the concept of inheritance, and how we could use it to create many different types of monsters. That made intuitive sense and fit within the conceptual model of inheritance, where objects can exist in descriptive hierarchies. A Goblin Archer is a specific type of Goblin; a Goblin is a specific type of Monster.

1class Monster {};
2class Goblin : public Monster {};
3class GoblinArcher : public Goblin {};

There are many other ways to solve this problem, however. An alternative approach is the concept of a type object. Here, our objects store their type as a variable.

1// Our monster types are represented by Breed objects
2class Breed {
3public:
4  int Level;
5  // ...other variables
6};
7
8// Our monster objects reference their breed
9class Monster {
10  const Breed& Breed;
11};

A conceptual way of thinking of this would be that our monster has a specific subtype, rather than it being a specific subtype. This pattern allows us to create any number of different "types" of monster, from only two classes.

Using Type Objects

There are two main ways to use this pattern. We can create Monsters as we would normally, passing a reference to the breed as the constructor:

1Breed Goblin { 10 };
2Monster MyGoblin { Goblin };

To enable this, our Monster class would need an appropriate constructor:

1class Monster {
2public:
3  Monster(const Breed& Breed) :
4   Level { Breed.Level },
5   Breed { Breed }
6  {
7    // Additional initialisation here
8  }
9private:
10  int Level;
11  const Breed& Breed;
12};

An alternative way to arrange our code might be to give our Breed objects the ability to create Monster objects:

1Breed Goblin { 500 };
2Monster MyGoblin { Goblin.Create() };

Either approach is valid - the relative advantages and disadvantages just depend on our specific requirements and preferences.

Benefits of this Design

This might seem like a strange way to achieve the same thing, but getting into a situation where we don't need to add a new class to create a new type of monster has many advantages.

When our different monster types are simply a collection of data, we are a step closer to being able to take them out of the code entirely. This ultimately allows us to build systems where our monster types can be defined at run time. This means we can do things like:

• Update types very quickly - no recompile necessary
• Let others update types without modifying code - eg, designers, players
• Define our types elsewhere - for example, in external tools or APIs
• In an online game, update types over the network - no patching necessary

Drawbacks of this Design

It's clear how this pattern allows us to initialise variables to different values based on our types. However, inheritance also gave us the ability to have different behaviours based on type. It's less obvious how we can do that using this pattern.

It is still possible to provide behaviors within the data. Some projects even build out the ability to have code injected at run time - programming languages such as LUA are commonly used for this purpose.

Another approach is to have the functions within the Monster class do different things based on values provided within the type data. For example, our type could include values representing personality traits. We might have a variable representing Aggression, and our AI functions would do different things based on that value. Then, if we wanted our monster to behave differently, we simply change that number.

However, despite these options being available, classic inheritance still gives us the most powerful and direct way of overriding behaviours to create different behaviours.

So Which Design Should I Use?

We've covered many different ways to achieve similar goals. We've seen classic inheritance, type objects, and component-based composition.

Components and Composition

An introduction to the component-based design pattern, allowing us to create extremely complex objects in a simple, maintainable way

Each have their advantages and disadvantages. Good software design is all about choosing the correct tool for the situation at hand. That can often involve a combination of different patterns, trying to find the mix that gets the best results for the specific project we're working on.