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?
Short answer: Yes. Actually, since Java 8 you can provide default implementations for the methods in an interface and the only differences to an abstract class are constructors (which you don't use anyway apparently) and fields which should be private, so there's very little difference.
Abstract Factory provides interfaces for creating families of related or dependent objects without specifying their concrete classes. Client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the family of objects.
When to Use Abstract Factory Pattern: The client is independent of how we create and compose the objects in the system. The system consists of multiple families of objects, and these families are designed to be used together. We need a run-time value to construct a particular dependency.
Advantage of Abstract Factory Pattern Abstract Factory Pattern isolates the client code from concrete (implementation) classes. It eases the exchanging of object families. It promotes consistency among objects.
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:
Create
method each, such as a GrenadeFactory
and a BulletFactory
CreateBullet
and CreateGrenade
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With