Question

I’m trying to design a good entity creation system with an abstract factory (as per http://www.dofactory.com/Patterns/PatternAbstract.aspx) but I’m struggling when it comes to instance specific parameters.

For example:
I have two abstract factories, one for creating a projectile, and one for creating a crate

Now the factory can be either be one instance for each type, which is passed an abstract parameter set from a list (which in the base class would shared material, size etc), type specific parameters would be velocity for a projectile and durability for a crate.

But what I’m struggling with is, in the end when I have this abstract factory method which I call with parameters like a string “BulletProjectile”, and “WeakCrate”, I need to provide instance specific parameters, and more importantly they are of different types for different factories – for projectiles they would have position and velocity, and crate would just have position.
A worse scenario is when the user or player is creating a crate or similar object, and is able to define its dimensions. How would I handle this?

Answer 1

A couple options:

Rethink your usage

An abstract factory is useful if it separates the user of the factory from how the exact type is produced. The abstract factory doesn’t have any restrictions on what it produces, just that it is abstract. It can return a non-abstract type, or an abstract type that isn’t at the very base of your inheritance hierarchy.

If code that uses the factory already can get different sets of data to call the factory with, then the code using the factory already has some knowledge of the type that comes out of it.

Here are some options to think about:

• Provide multiple abstract factory types, with one Create method each, such as a GrenadeFactory and a BulletFactory
• Provide multiple methods on a single abstract factory type, such as CreateBullet and CreateGrenade
• Stop using abstract factories. This is a good option if you don’t really need abstract construction, and just need abstract types.

Remember that you can still pass a derived type (Bullet) to a method taking a base type (say, Entity or Projectile).

Double dispatch

If you’re really dead set on combining abstract factories with abstract parameters, then you may want to look into double dispatch, or the Visitor Pattern. The key here is that you’re trying to get two different virtual methods to be combined with each other, and get a unique combination of behavior based on those two derived types.

This would require you to create base and derived types for your parameters, so you couldn’t pass simple types (like int, string, etc) without creating a custom parameter structure that derived from a base Parameters type.

It also requires a lot of extra code to implement the Visitor pattern.

RTTI

You could use the C++ Run-Time Type Information feature.

Using dynamic_cast, you can cast a base type to a derived type. You could do this in the factory implementation to cast your base parameter type to your specific parameter type.

Like double-dispatch, this would also require you to create a type hierarchy for parameters, but would require less code to stitch them together (wouldn’t require the visitor pattern).

This option would tightly couple your factory implementation to a parameter structure implementation, though.

Property bag

You can also use a string -> some type dictionary (string -> boost::any, for example). This is called a property bag. It loses you a lot of compile time type safety, though, because you’re basically looking everything up by string value. I don’t really recommend it.