Description / Meta Description
Learn the Prototype Design Pattern in Java with practical examples. Understand when cloning objects is better than creating new ones, shallow vs deep copy, performance benefits, real-world use cases, and how Prototype differs from Factory and Builder patterns.
Prototype Design Pattern in Java: Creating Objects by Cloning Instead of Using new
In our Creational Design Pattern journey, we’ve explored:
- Singleton → One shared instance
- Factory Method → Decide which object to create
- Builder → Construct complex objects step-by-step
- Abstract Factory → Create families of related objects
Now we arrive at perhaps the least used—but highly valuable in certain scenarios—Creational Pattern:
Prototype Pattern
Unlike previous patterns that focus on object creation through constructors or factories, Prototype takes a completely different approach:
Instead of creating a new object from scratch, create it by cloning an existing one.
The Problem: Object Creation Can Be Expensive
Most developers assume object creation is always cheap.
Example:
Employee employee =
new Employee();
For simple objects, that’s true.
But consider an object that requires:
- Database queries
- Configuration loading
- File parsing
- API calls
- Complex initialization
Example:
public class ReportTemplate {
public ReportTemplate() {
loadConfiguration();
loadImages();
loadFonts();
connectToStorage();
}
}
Now imagine creating 10,000 such objects.
Create Object
↓
Heavy Initialization
↓
Create Object
↓
Heavy Initialization
↓
Repeat 10,000 Times
Performance suffers.
What is Prototype Pattern?
Prototype is a Creational Design Pattern that:
Creates new objects by copying existing objects instead of constructing them from scratch.
Think of it like:
Original Object
│
▼
Clone
│
▼
New Object
The cloned object already contains most of the required state.
Real Life Analogy
Suppose you need 100 copies of a company ID card.
Option 1:
Create each card manually.
Option 2:
Create one card
↓
Photocopy 99 times
Which is faster?
The Prototype Pattern follows the photocopy approach.
Basic Prototype Example
Step 1: Create Prototype Interface
The prototype contract defines a cloning operation.
public interface Prototype {
Prototype clone();
}
Unlike Factory or Builder patterns, the focus here is not on construction.
The focus is on copying existing objects.
Step 2: Create a Concrete Prototype
Suppose we have an Employee object.
public class Employee
implements Prototype {
private String name;
private String department;
public Employee(String name,
String department) {
this.name = name;
this.department = department;
}
@Override
public Employee clone() {
return new Employee(
this.name,
this.department);
}
@Override
public String toString() {
return name + " - " + department;
}
}
Step 3: Clone Existing Objects
Employee original =
new Employee(
"Rahul",
"Architecture");
Employee copy =
original.clone();
Verification:
System.out.println(original);
System.out.println(copy);
Output:
Rahul - Architecture
Rahul - Architecture
Two independent objects now exist.
Why Not Just Use new?
Good question.
For simple objects:
new Employee(...)
is perfectly fine.
Prototype becomes useful when:
Object creation is expensive
OR
Object state is complex
OR
Object configuration is dynamic
Real-World Example: Report Templates
Imagine an enterprise reporting platform.
A report contains:
Header
Footer
Fonts
Images
Company Branding
Watermarks
Charts
Creating each report requires:
Load Fonts
Load Images
Load Configurations
Initialize Templates
Expensive process.
Instead:
Create One Master Template
│
▼
Clone As Needed
Example:
ReportTemplate master =
loadMasterTemplate();
ReportTemplate report1 =
master.clone();
ReportTemplate report2 =
master.clone();
Huge performance savings.
Shallow Copy vs Deep Copy
This is where Prototype becomes interesting.
Many Java developers struggle with cloning because they don’t understand the difference between:
Shallow Copy
Deep Copy
Shallow Copy
Suppose:
class Address {
String city;
}
class Employee {
String name;
Address address;
}
Original object:
Employee
│
▼
Address
Shallow copy:
Original Employee
│
▼
Address
Cloned Employee
│
▼
Same Address
Notice:
Both objects share the same nested object.
Example:
Employee clone =
original.clone();
Then:
clone.address.city = "Mumbai";
Result:
Original Address = Mumbai
Clone Address = Mumbai
Unexpected behavior.
Deep Copy
Deep copy duplicates everything.
Original Employee
│
▼
Address
Clone Employee
│
▼
New Address
Now changes remain isolated.
clone.address.city = "Mumbai";
Result:
Original = Delhi
Clone = Mumbai
Much safer.
Deep Copy Example
public Employee clone() {
Address clonedAddress =
new Address(
this.address.getCity());
return new Employee(
this.name,
clonedAddress);
}
Now nested objects are copied as well.
Java Cloneable Interface
Historically Java introduced:
Cloneable
Example:
public class Employee
implements Cloneable {
@Override
protected Object clone()
throws CloneNotSupportedException {
return super.clone();
}
}
Usage:
Employee copy =
(Employee) original.clone();
Why Cloneable Is Often Avoided
Many senior Java developers avoid:
Cloneable
because:
- confusing API design
- shallow copy issues
- checked exceptions
- difficult inheritance handling
Joshua Bloch (Effective Java) famously criticized it.
Modern systems usually implement custom copy logic.
Prototype Registry Pattern
A powerful variation is maintaining prototypes in a registry.
Instead of:
new ReportTemplate()
everywhere,
store prototypes centrally.
Map<String, ReportTemplate>
templates = new HashMap<>();
Load once:
templates.put(
"SALES",
salesTemplate);
templates.put(
"FINANCE",
financeTemplate);
Usage:
ReportTemplate report =
templates
.get("SALES")
.clone();
This combines:
Registry
+
Prototype
A common enterprise design.
Architecture Diagram
Prototype Registry
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Sales Template Finance Template HR Template
│ │ │
▼ ▼ ▼
Clone Clone Clone
│ │ │
▼ ▼ ▼
Report A Report B Report C
Real-World Use Cases
Prototype appears more often than people realize.
Document Templates
Microsoft Word:
Invoice Template
Contract Template
Resume Template
New documents are clones of templates.
Game Development
Games frequently clone:
Enemy Objects
Weapons
Characters
Vehicles
instead of building from scratch.
Workflow Engines
Enterprise workflow systems often clone:
Process Definitions
Approval Flows
Task Templates
Cloud Infrastructure
Infrastructure-as-Code tools effectively clone:
VM Templates
Container Templates
Network Templates
Prototype vs Factory
Developers often confuse these.
Factory Pattern
Creates:
Brand New Object
Example:
Payment payment =
factory.create();
Prototype Pattern
Creates:
Copy Of Existing Object
Example:
Payment payment =
prototype.clone();
Prototype vs Builder
Builder:
Step-by-Step Construction
Example:
Customer.builder()
.name("Rahul")
.email("test@test.com")
.build();
Prototype:
Copy Existing State
Example:
Customer clone =
existingCustomer.clone();
Quick Comparison of Creational Patterns
| Pattern | Purpose |
|---|---|
| Singleton | Ensure one instance |
| Factory Method | Create one object |
| Builder | Construct complex object |
| Abstract Factory | Create object families |
| Prototype | Clone existing objects |
Think of them as answering different questions:
Singleton
→ How many objects?
Factory
→ Which object?
Builder
→ How do I construct it?
Abstract Factory
→ Which family of objects?
Prototype
→ Can I copy an existing object?
When Should You Use Prototype?
Use Prototype when:
✔ Object creation is expensive
✔ Initialization takes significant time
✔ Existing state should be reused
✔ Templates are common
✔ Cloning is simpler than reconstruction
Avoid Prototype when:
❌ Objects are simple
❌ Deep copy complexity becomes excessive
❌ Object graphs are difficult to clone safely
Final Thoughts
The Prototype Pattern solves a unique problem:
Why rebuild something from scratch when you can clone an existing, fully configured object?
Although less common than Singleton or Builder, Prototype can deliver significant performance and flexibility benefits in systems that rely heavily on templates, reusable configurations, and expensive object initialization.
With this article, we’ve completed the five Gang of Four Creational Design Patterns:
- Singleton
- Factory Method
- Builder
- Abstract Factory
- Prototype
In the next article, we’ll begin the second major GoF category:
Structural Design Patterns — Organizing Objects and Classes for Flexible System Design
We’ll start with one of the most practical patterns used daily in enterprise systems:
