CREATIONAL

Factory

What Is It?

Factory Pattern is a creational design pattern that moves the responsibility of creating objects away from the main code and into a separate factory class or method. Instead of writing new Goblin() or directly calling Instantiate(zombiePrefab) everywhere, the code simply asks the factory for the object it needs.

In Unity, this can be imagined as an enemy spawning system. The GameManager does not need to know how a Goblin, Orc, Dragon, or Boss is created. It only asks the EnemyFactory for an enemy.

The main idea is to keep object creation in one place and prevent the rest of the project from depending too much on concrete classes.

When Is It Used?

Factory Pattern is useful when a project needs to create different types of objects from the same family. For example, a game may have several enemy types, weapon types, bullets, visual effects, or UI windows, and the correct one may need to be chosen during gameplay.

It is commonly used when:

Object creation logic starts becoming repetitive or complex
The object type is decided at runtime
Prefab selection, spawn position, stats, or setup logic should be handled in one place
The rest of the code should not depend directly on concrete classes
The creation system needs to work together with Object Pooling

However, Factory Pattern is not always necessary. If the project only creates one simple object type, using a factory may add extra structure without much benefit.

Animation

Enemies Created

Code

Assets / Scripts / Creational / Factory›EnemyFactory.cs

READ ONLY

using UnityEngine;

namespace Patterns.Creational.Factory
{
    public enum EnemyType
    {
        Goblin,
        Orc,
        Dragon
    }

    public class EnemyFactory : MonoBehaviour
    {
        [SerializeField] private GameObject _goblinPrefab;
        [SerializeField] private GameObject _orcPrefab;
        [SerializeField] private GameObject _dragonPrefab;

        public IEnemy CreateEnemy(EnemyType type, Vector3 position)
        {
            GameObject prefab = type switch
            {
                EnemyType.Goblin => _goblinPrefab,
                EnemyType.Orc => _orcPrefab,
                EnemyType.Dragon => _dragonPrefab,
                _ => throw new System.ArgumentException($"Unknown type: {type}")
            };

            var instance = Instantiate(prefab, position, Quaternion.identity);
            return instance.GetComponent<IEnemy>();
        }
    }
}

Advantages and Disadvantages

• Advantages:

Keeps creation logic in one central place.
Makes the code easier to extend.
Reduces dependency on concrete classes.
Improves testability by allowing mock factories.
Makes spawn and setup logic easier to control.
Works well with Object Pooling for better performance.

• Disadvantages:

Can add unnecessary complexity to simple systems.
May increase the number of classes and files.
Can make it harder to trace where an object is created.
May lead to over-engineering if used too early.
Large switch-case structures can become hard to maintain.

Tips

When using Factory Pattern in Unity, it is usually better to return an interface or abstract type instead of a concrete class.

Prefab references should be managed cleanly. Instead of hardcoding them inside the script, use SerializeField or ScriptableObjects.

For objects that are created often, such as bullets, hit effects, or enemies, Factory Pattern works very well with Object Pooling.

In larger projects, a Dictionary-based factory can be cleaner than a long switch-case block.

It is also important not to make one factory responsible for everything. Related object groups should usually have separate factories.

Back to All Patterns