Abstract factory with abstract parameters?

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?

Paradies

When I said either in the second paragraph, my second option would be to have a different instance of the factory for each type. (an instance of ProjectileFactory for both Bullet and Grenade – Paradies

@Alas: Have you tried gamedev.stackexchange.com ? Maybe you have more luck there, since you're especially asking for game-development. – Nothing

Its not a game development specific issue, I just thought I'd tag it such since thats the example I'm using. Just pretend they're web forms instead of bullets I'm creating ;) – Paradies

@Alas: Sure, just thought it might help you more. :) – Nothing

Gettings tonnes of up-votes because its a tough question :/ I just can't think of a solution to it – Paradies

On another note, do you really need that abstract factory pattern? I can't really wrap my head around how it would handle registering new types and stuff... – Nothing

@Alasdair have you considered using a more TDD approach and just start with the simplest thing(or the dumbest thing) that could work? Keep refactoring it and let the natural pattern emerge. This may or may not be an abtract factory. The thing is if you find you're fighting tooth and nail trying to get the pattern to fit, it may be that pattern isn't really appropriate here. – Basrelief

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.

Windmill

What would you suggest then? I do need a good way to carry the parameters for certain entity creation methods, but I also would like to be able to serialise a set of factory parameters in a level file. – Paradies

@Alasdair: Abstract factories are most useful for runtime decoupling, not really for serialization. You'll probably get a lot better performance by doing binary serialization of live state, though of course your data won't be platform independent... – Windmill

@Merylyn: I want to have two passes on serialization though. I have predefined levels which have been created in an editor, and thats loaded in first, and then after that a save file can be loaded in which is a state, which modifies existing entities (can move them, change their health or kill them), and new entities that have been spawned. – Paradies

@Alasdair: I understand the general requirements, but I'd really have to see your code to give you good suggestions on how to refactor it. Any other way and it is the blind leading the blind :) If you want specific code feedback, you could try codereview.stackexchange.com. – Windmill

@Merlyn: Ah well I've not written anything for this yet, I've been using a different implementation which I've just come to the conclusion that I don't like – Paradies

That RTTI implementation is pretty much what I use right now (I use unions instead of inheritence since I'm going to know what I am using), its a method I've ended up not particularly liking because I have to modify this (what should be) set field of parameters for each instance – Paradies

@Alasdair: The union should be faster than RTTI, actually. I don't think there is any run-time type conversion involved. – Windmill

@Merlyn Thanks for the answer, I've decided to use property bag, it works great, I know its slower but I'm gonna optimise it with indexed hashing – Paradies

@Alasdair: Sounds good. One more bit of advice is to fail loudly and fail early on missing-property access, since it will aid in debugging. – Windmill