Prototype Pattern
What it is:
Instead of creating new objects from scratch, you make copies of existing ones (called
“prototypes”). Think of it as duplicating a document template.
Why it’s useful:
• When creating a new object is expensive or complicated.
• When you want to avoid writing a lot of new code for objects that are almost the
same.
Analogy:
Imagine you’re filling out forms for 100 students. Instead of writing the whole form from
scratch every time, you make one master copy and duplicate it. Then, for each student, you
just fill in their name and roll number. The prototype form saves you time and effort.
Key idea:
• Keep a prototype (master object).
• Copy it whenever you need a new one.
• Make small changes to the copy if needed.
Use when:
• Object creation is expensive/complex.
• You need many similar objects (with small tweaks).
• You want to avoid binding code to concrete classes at creation time.
Key parts: Prototype (declares clone()), concrete prototypes that implement cloning,
and client code that asks a registry (optional) for a copy.
-------------------------------------------------------------------------------------------------------------------
Command Pattern
What it is:
Turn an action (like “turn on light” or “print document”) into a separate object called a
command. This allows you to store, queue, undo, or send actions around easily.
Why it’s useful:
• When you want undo/redo operations.
• When you want to log or schedule actions.
• When you want to keep the button (caller) and the light (doer) separate.
Analogy:
Think about a restaurant:
• The Waiter is the Invoker.
• The Order Slip is the Command (it contains what needs to be done, like “make
pasta”).
• The Chef is the Receiver (the one who actually cooks).
The waiter doesn’t cook, and the chef doesn’t take orders. The slip (command) acts as the
middleman. You could even stack slips (queue commands), cancel one (undo), or repeat
an order (redo).
Key idea:
• Wrap each request as an object.
• The invoker (like a button or waiter) doesn’t know how the action is carried out.
• The receiver (like a light or chef) does the real work.
This follows the Command Pattern because:
1. Action is wrapped in a Command object – The request “turn on light” is not called
directly. Instead, it is wrapped inside LightOnCommand, which implements the
Command interface.
2. Invoker and Receiver are decoupled – The Remote (Invoker) doesn’t know how
the Light works. It only knows it can call execute() or undo() on some Command.
The real work is done by the Light (Receiver).
3. Undo is supported – Because the command object keeps track of the receiver, it
can reverse the action ([Link]() when undo is called).
In short: The pattern converts a request (turning the light on/off) into an object
(LightOnCommand) so that the invoker (Remote) and receiver (Light) are loosely
coupled, and actions can be executed, undone, or swapped flexibly.
Quick difference in one line:
• Prototype is about duplicating objects efficiently.
• Command is about packaging actions so they can be managed flexibly.