Prototype Pattern

# CHAPTER 10

Prototype Pattern #

1. Introduction #

2. Learning Objectives #

• Define the intent and performance benefits of the Prototype Pattern.

• Understand how to implement a common clone interface.

• Differentiate between a "Shallow Copy" and a "Deep Copy" in memory architecture.

• Identify scenarios where cloning is superior to standard instantiation.

• Implement a Prototype Registry to store default object templates.

3. The Core Concept #

• The Process: You create one "Master" object (the Prototype). You run its heavy constructor once. When you need a new object, you simply ask the Prototype to duplicate itself.

• The Decoupling: The client code requesting the clone doesn't even need to know the concrete class of the object it is cloning. It just interacts with a generic Prototype interface.

4. Deep Copy vs. Shallow Copy #

• Shallow Copy: When you clone an object, the primitive variables (strings, integers) are copied. However, if the object contains a *reference* to another object (e.g., the Orc has a Weapon object), the clone *shares* the exact same Weapon object in memory. If Clone A upgrades the weapon, Clone B's weapon is upgraded too. This is usually a bug.

• Deep Copy: When you clone an object, you write specific code to recursively clone every single internal object reference as well. Clone A and Clone B get entirely independent, separate Weapon objects in memory.

5. The Prototype Registry #

• The Concept: You create a central "Registry" (often combined with a Factory or Singleton). When the application boots up, you create standard templates: a BasicOrc, a BossOrc, a FastOrc, and store them in the registry hash map.

• The Execution: When the game requests a "Boss", the registry looks up the BossOrc template, clones it, and returns the fresh, independent clone instantly.

6. UML Diagram #

[ Client ] ---------------------> [ <<Interface>> Prototype ]
                                  + clone(): Prototype
                                           ^
                                           | (Implements)
                                  [ ConcretePrototype ]
                                  - field1
                                  - field2
                                  + clone() { return copy of self }

7. Code Example (PHP) #

<?php
// --- 1. A Dependent Object ---
class Weapon {
    public $damage;
    public function __construct($damage) { $this->damage = $damage; }
}

// --- 2. The Prototype Class ---
class OrcSoldier {
    public $health;
    public $weapon; // Object reference

    public function __construct($health, Weapon $weapon) {
        // Imagine this takes 2 seconds of heavy CPU time to run!
        echo "Running heavy Orc constructor...\n";
        $this->health = $health;
        $this->weapon = $weapon;
    }

    // 3. The Cloning Logic (Deep Copy)
    public function __clone() {
        // PHP automatically does a Shallow Copy.
        // We must manually clone internal object references for a Deep Copy.
        $this->weapon = clone $this->weapon;
    }
}

// --- 4. Client Code ---

// Create the Prototype ONCE. (Heavy operation)
$heavyIronSword = new Weapon(50);
$prototypeOrc = new OrcSoldier(100, $heavyIronSword);
// Output: Running heavy Orc constructor...

// We need an army of 1,000 Orcs. 
// We DO NOT run the constructor 1,000 times. We CLONE.
echo "Cloning Orc 1...\n";
$orc1 = clone $prototypeOrc; // INSTANT. Constructor is bypassed.

echo "Cloning Orc 2...\n";
$orc2 = clone $prototypeOrc; // INSTANT.

// Prove Deep Copy worked: Modify Orc 1's weapon.
$orc1->weapon->damage = 999;

// Orc 2's weapon is safe, proving they don't share memory.
echo "Orc 1 Weapon Dmg: " . $orc1->weapon->damage . "\n"; // Output: 999
echo "Orc 2 Weapon Dmg: " . $orc2->weapon->damage . "\n"; // Output: 50
?>

8. Best Practices #

• Serialization for Deep Copies: Writing recursive __clone() methods for objects nested 5 layers deep is exhausting and error-prone. A common architectural "hack" in many languages is to serialize the object to a string (or JSON), and immediately deserialize it. The resulting object is mathematically guaranteed to be a perfect, memory-isolated Deep Copy.

9. Common Mistakes #

• Ignoring the Constructor Bypass: When you clone an object, its constructor is *not* executed. If your constructor contains critical business logic (e.g., incrementing a global "Total Active Users" counter), cloning the user will bypass this logic, causing your analytics to break. You must manually execute required logic after a clone.

10. Mini Project: Build an Invoice Template System #

1. 1. The Goal: Generating a PDF Invoice with standard company headers takes a long time.

1. 2. The Prototype: Create an Invoice class. In the constructor, execute a fake sleep(2) to simulate generating complex HTML headers.

1. 3. The Registry: Create a system that initializes one StandardInvoice and one PremiumInvoice on startup.

1. 4. The Action: When a customer requests a receipt, clone the requested template, change the Customer Name variable, and return it instantly without triggering the 2-second delay.

11. Practice Exercises #

1. 1. Define the primary performance advantage of the Prototype Pattern compared to traditional object instantiation using the new keyword.

1. 2. Explain the critical distinction between a "Shallow Copy" and a "Deep Copy." Why does failing to execute a Deep Copy result in dangerous shared-memory bugs?

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain a specific scenario where the computational cost of object initialization forces an architect to abandon the Factory Pattern in favor of the Prototype Pattern.

• Q: Walk me through the mechanics of a "Deep Copy." If you have an object that contains an array of objects, which contain references to other objects, how do you architect a safe cloning process to ensure complete memory isolation?

• Q: What is a Prototype Registry, and how does it combine the concepts of the Prototype Pattern and the Factory Pattern to manage application state?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #