# Changing game object type: reinstantiating the object, or switching an object state

I work on a strategy game, where the player occasionally has to transform ordinary citizens into the so called "leaders". Leaders are temporary units, which the player can control directly, in order to interact with the other citizens. After some time, the leader gets transformed back to a normal citizen.

My question is if I should stick to the classical OOP approach of keeping citizens and leaders in two separate classes, whereas the leader class extends the citizen class, and every time when I need a leader, I simply re-instantiate the current citizen instance.

I personally dislike this approach, however. I already have a state machine implemented, and am more likely to keep only the citizen class (or rather, human class). Rather, I'd like to keep the citizen/leader separation into two different states. When I need one or the other type, I simply switch the current state.

Most games don't have different classes for different entity types, because it's not very flexible. Your example is a classic case of why this is so! Classical OO with one-class-per-noun is great for toy problems but not so good in the real world.

I'd suggest using the Strategy pattern, and swapping out a behaviour object that encapsulates the key differences between the two types of character, leaving the rest of the entity unchanged.

With a components-based entity system, you can simply do

if (citizen.leaderComponent)
{