Prototype vs Factory: Trade-offs and When to Use

Decision Framework:
Both Prototype and Factory patterns create objects, but they solve different problems. Use Prototype when object creation is expensive or when objects have complex runtime state. Use Factory when you need centralized creation logic or when object construction is straightforward but type selection is dynamic.
Prototype Pattern
When: Creating objects is expensive (DB queries, file loading, heavy computation).

Benefit: Avoids reconstruction cost by copying existing instances.

Example: Game enemy with loaded textures, AI state, inventory.
vs
Factory Pattern
When: Object creation is simple but type selection depends on input.

Benefit: Centralized creation logic, easy to add new types.

Example: Vehicle factory returning Car, Truck, or Bike based on type string.
When Prototype is Appropriate:
First, when initialization involves external resources (database records, file parsing, network calls) that you want to avoid repeating. Second, when objects have complex configurations that are easier to copy than reconstruct. Third, when you need many similar objects with slight variations. However, if objects are simple POJOs (Plain Old Java Objects) with no expensive initialization, a factory with a constructor is clearer and more maintainable.
When Prototype is Overkill:
For simple value objects or DTOs (Data Transfer Objects), direct construction is simpler. If cloning logic becomes complex (deep nested structures, circular references), the maintenance burden outweighs benefits. In such cases, consider Builder pattern for complex construction or Factory for simpler type-based instantiation.
Common Mistake: Using Prototype for all object creation without measuring actual cost. Profile first. If object construction takes microseconds, the added complexity of clone methods isn't justified.
Combining Patterns:
You can use both together. A factory can maintain a registry of prototype objects and return clones instead of creating from scratch. This is called a Prototype Registry or Prototype Factory. For example, a ShapeFactory stores pre-configured shape prototypes (red rectangle, blue circle) and clones them on request. This combines the type selection benefit of Factory with the efficiency of Prototype.
class ShapeFactory:
  prototypes = {
    "red-rect": new Rectangle(color=RED),
    "blue-circle": new Circle(color=BLUE)
  }

  function createShape(type: String):
    if type in prototypes:
      return prototypes[type].clone()
    else:
      throw UnknownTypeError
Interview Tip: Always discuss trade-offs explicitly. Say "I'd use Prototype here because X, but if Y were true instead, Factory would be better." This demonstrates decision-making ability, not just pattern knowledge.

💡 Key Takeaways

✓Use Prototype when object creation is expensive or involves external resources

✓Use Factory when creation is simple but type selection is dynamic

✓Prototype can be overkill for simple value objects and DTOs

✓Combining Prototype and Factory creates a Prototype Registry pattern

✓Always profile before optimizing with Prototype for creation cost

📌 Examples

1Prototype: game enemies with loaded assets and AI state

2Factory: vehicle creation based on type string input

3Combined: shape factory with pre-configured prototype templates

← Back to Prototype Pattern Overview