Is having a master builder object a bad idea?

Question

I have wondered about using the following approach to creating Entity objects in a personal project. What I want is to be able to keep track of all Entity objects that get created, so whenever an instance is created, it should automatically get added to a bookkeeping list.

The approach I thought of using is to create a class that can hand out new Entity objects, rather than allowing them to be created directly. This class is called EntityFactory. It's not the factory pattern though. Basically, I define my Entity base class with a private constructor and made EntityFactory a friend class so that it could instantiate Entity objects and hand them out.

The only downside I can see is that I would have to pass around the EntityFactory object.

Will there be other problems? Is this a bad idea? If so, what alternatives are there to have automatic tracking of all Entity objects that get instantiated.

Answer 1

This is still, essentially, a factory, just not one that creates things via runtime keys. It uses compile-time keys (effectively) instead.

You have touched on the major downside: you'll need to make this factory accessible everywhere you want to be able to create entities. This, however, is also an upside because it means you can control what interfaces are allowed to create objects on a very granular level: if you don't give an interface access to the factory, it can't create new things.

Whether or not you actually need all entities to automatically be tracked somewhere aside, this is a more reasonable pattern for doing so than putting that code in, for example, the entity constructor, since it does not overly pessimize your code against the future need to create entities that aren't tracked (perhaps for testing scenarios, or lazy evaluation, et cetera).

Answer 2

A method which I used for one of my projects is to create a parent class which precedes over all entities and then I used polymorphism to make all the entities the type of the Parent.

Essentially you'll make a list of type Entity and then when you want to modify a specific type then you cast it to its original class type to access any variables that the parent class wouldn't have access to.

You add the specific Entity to the list by casting it to what the parent would class would be. In this case Entity.

Essentially it would look something like this:

Dog d;
Cat c;
Bird b;

Animal AnimalList;

AnimalList.add(static_cast<Animal> d);
AnimalList.add(static_cast<Animal> c);
AnimalList.add(static_cast<Animal> b);

The benefits of this method are you will have a permanent list of objects of the same type and thus will make things easier for, for example, collision detection or updating all of their positions. As you will have a neat list to compare against rather than several lists.

for(int i = 0; i < AnimalList.size(); i++)
{
AnimalList.at(i).update();
AnimalList.at(i).collisionCheck();

if(AnimalList.at(i) == type(Dog))
{
Dog d = static_cast<Dog>AnimalList.at(i);
d.bark(); //Poor example as you'd probably have multiple creatures having a Cry() //method so they could all have the same function like update();
}
}

However it becomes a problem when you want to do checks against specific types. In that case you will have to scour through the list checking against all of the the types to find the right ones. A bypass to this maybe making a indices list for items you want to specifically keep track of. Though I doubt you'll be seeing any performance issues unless you're dealing with a huge list of Entities.