Prototype Pattern
Prototype: start from the problem
See the responsibilities
A report starts from a configured template with nested display settings. Creating each report from scratch repeats setup. Sharing the same mutable settings object lets one customer’s change affect another report.
This is a creational pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Prototype addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Prototype creates a new object by copying an existing exemplar. The exemplar supplies a starting configuration; the copying policy determines which values are shared and which are independent. It is especially important to decide how nested mutable values behave.
The example clones a plain-data template with structuredClone, then edits the new report’s nested theme. Prototype as a design pattern is different from JavaScript’s prototype-chain mechanism for property lookup.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const template = {type: 'report', options: {theme: 'light'}};
const report = structuredClone(template);
report.options.theme = 'dark';
console.log(template.options.theme + ' | ' + report.options.theme);Expected output
light | darkChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when a configured example is a useful starting point and rebuilding it is awkward or expensive. Make identity and ownership choices explicit when a copy enters storage.
A shallow copy shares nested references. Deep copying can be expensive and cannot blindly recreate live connections, functions or external identities. structuredClone here supports the chosen plain data; it does not copy every possible application object with its class behaviour.
Distinguish the neighbouring patterns
Builder constructs through explicit steps. Prototype begins from an existing object. Flyweight intentionally shares safe common data rather than creating independent mutable copies.
Follow Builder’s explicit assembly, Flyweight’s deliberate sharing, identity and stored records to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Prototype, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside identity and stored records.
Reaching the recap and completing the quizzes are separate milestones.