Factory Pattern
Sometimes it’s helpful to have a special object that creates other objects. The factory pattern designates a special object called – you guessed it – a factory for this purpose. On one level, it encapsulates many of the details
involved in spawning its “products.” However, if each product follows a common interface or base class, you can take this a step further and make it contain more of its own construction logic, hiding it away from the factory
itself. You can also subclass the factory to make multiple factories dedicated to specific products. Doing this helps generate enemies, obstacles, or anything else at runtime.
Example
Factories might need some shared
common functionality, so this sample uses
abstract classes. Just be mindful of Liskov
substitution from the SOLID principles when Products need to follow a specific template
using subclasses. for their methods, but they don’t otherwise
share any functionality. Hence, you define
the IProduct interface.
The base class, Factory, has a
GetProduct method that returns an
IProduct. It’s abstract, so you can’t
make instances of Factory directly. You
derive a couple of concrete subclasses
(ConcreteFactoryA and
ConcreteFactoryB), which will actually
get the different products.
GetProduct in this example
takes a Vector3 position so
that you can instantiate a
Prefab GameObject more
easily at a specific location. The IProduct interface defines what is common
between your products. In this case, you simply
have a ProductName property and any logic the
product runs on Initialize. You can then define as
many products as you need (ProductA, ProductB,
etc.) so long as they follow the IProduct interface.
A field in each The product classes are MonoBehaviours that
concrete factory stores the implement IProduct take advantage of Prefabs in
corresponding template the factory.
Prefab.
Each product can have its own version of Initialize.
The example ProductA Prefab contains a
ParticleSystem, which plays when
the ConcreteFactoryA instantiates a copy. The
factory itself does not contain any specific logic for
triggering the particles; it only invokes the
Initialize method, which is common to all products.
Pros and cons
Pros Cons
You’ll benefit the most from the factory pattern when
setting up many products. Defining new product
The downside is that you create a number of
types in your application doesn’t change your
classes and subclasses to implement the pattern.
existing ones or require you to modify previous
Like the other patterns, this introduces a bit of
code. Separating each product’s internal logic into
overhead, which may be unnecessary if you don’t
its own class keeps the factory code relatively short.
have a large variety of products.
Each factory only knows to invoke Initialize on each
product without being privy to the underlying details.
Improvements
Use a dictionary to search for products Make the factory (or a factory manager) static Apply it to non-GameObjects and non-MonoBehaviours Combine with the object pool pattern
You might want to store your products as key-value pairs in a Factories don’t necessarily need to instantiate or create new
dictionary. Use a unique string identifier (e.g., the Name or This makes it easier to use but requires additional setup. Don’t limit yourself to Prefabs or other Unity-specific objects. They can also retrieve existing ones in the hierarchy.
some ID) as the key and the type as a value. This can make Static classes won’t appear in the Inspector, so you will need components. The factory pattern can work with any C# If you are instantiating many objects at once,
retrieving products and/or their corresponding factories to make your collection of products static as well. object. (e.g., projectiles from a weapon), use the object pool pattern
more convenient. for more optimized memory management.