Prototype Design Pattern in Java

The Prototype pattern creates a new object by copying the state of an existing object. The existing object provides the starting configuration, and a copy operation returns a separate instance. This is useful when an application needs another object with nearly the same settings but must allow the two objects to change independently.

1. How the Prototype Pattern Works

A constructor normally receives the values needed to initialize an object. With Prototype, the caller starts with an object that already has those values and asks it for a copy. The class implements the copying rules, so calling code does not need to read every field and repeat the construction logic.

The existing object is the prototype. Its copy operation creates the new instance, and the code requesting that instance is the client. If several classes support copying, they can declare the operation in a common interface. The client can then request a copy without selecting a constructor for each concrete class. A single class can also provide a copy method directly when the application does not need that abstraction.

A new top-level instance does not necessarily have independent mutable fields. If both instances refer to the same mutable list or element, changing that shared data affects both. The copy operation must decide which values can be shared and which nested objects need their own copies.

2. Prototype Pattern in Action

Consider a newsletter editor with a Duplicate campaign feature. An editor prepares a campaign with a sender address, a subject and several content sections. To prepare the next issue, the editor duplicates that campaign, keeps its structure and replaces the content that has changed. Editing the new issue must leave the original campaign intact.

Our Campaign class stores those values. Each nested Section has a heading and an editable body. Campaign.copy() creates another campaign with the same values, and PrototypeDemo is the client that requests the copy and edits it.

First, the application creates a campaign to use as the starting configuration:

Campaign template = new Campaign("news@example.com", "Monthly update",
        List.of(new Campaign.Section("News", "Add this month's news"),
                new Campaign.Section("Events", "Add upcoming events")));

The duplicate operation then creates an October issue and changes its subject and first section:

Campaign october = template.copy();
october.setSubject("October update");
october.section(0).setBody("Our new store opens Friday");

The october campaign retains the sender address and the Events section from template. Its subject and News body now contain the October values. For this to work, copy() must create separate mutable sections, not just a separate Campaign instance. The following implementation makes that ownership explicit.

3. Implementing the Copy Operation

We can implement copying with a copy constructor: a constructor that accepts an existing instance of the same class. Here, copy() calls a private copy constructor, which passes the original values to the ordinary constructor. That constructor creates the campaign’s own list and copies each section into it.

The nested Section class is static, so a section can be created without an existing campaign. Its fields hold the heading and editable body. Calls to Objects.requireNonNull() reject null values before they enter either class. The complete implementation is:

package com.howtodoinjava.patterns.creational.prototype;

import java.util.ArrayList;
import java.util.List;
import java.util.Objects;

public final class Campaign {
    private final String sender;
    private String subject;
    private final List<Section> sections;

    public Campaign(String sender, String subject, List<Section> sections) {
        this.sender = Objects.requireNonNull(sender);
        this.subject = Objects.requireNonNull(subject);
        this.sections = copySections(Objects.requireNonNull(sections));
    }

    private Campaign(Campaign original) {
        this(original.sender, original.subject, original.sections);
    }

    public Campaign copy() {
        return new Campaign(this);
    }

    private static List<Section> copySections(List<Section> source) {
        List<Section> result = new ArrayList<>();
        for (Section section : source) {
            result.add(new Section(Objects.requireNonNull(section)));
        }
        return result;
    }

    public void setSubject(String subject) {
        this.subject = Objects.requireNonNull(subject);
    }

    public String getSender() { return sender; }
    public String getSubject() { return subject; }
    public Section section(int index) { return sections.get(index); }

    @Override
    public String toString() {
        return subject + " | " + sections;
    }

    public static final class Section {
        private final String heading;
        private String body;

        public Section(String heading, String body) {
            this.heading = Objects.requireNonNull(heading);
            this.body = Objects.requireNonNull(body);
        }

        public Section(Section original) {
            this(original.heading, original.body);
        }

        public String getHeading() { return heading; }
        public String getBody() { return body; }

        public void setBody(String body) {
            this.body = Objects.requireNonNull(body);
        }

        @Override
        public String toString() {
            return heading + ": " + body;
        }
    }
}

Calling template.copy() executes new Campaign(this). Inside the copy constructor, original refers to the campaign being copied. The constructor passes its sender, subject and sections to the three-argument constructor. That constructor calls copySections(), which allocates an empty ArrayList and adds a new Section for every original section. The new campaign therefore has both a separate list and separate section instances.

The section copy constructor assigns the existing heading and body values to the new section. Those values are strings. Java’s String class is immutable, so sharing a string reference does not allow either campaign to change that string. When setBody() runs, it assigns a different string reference to the copied section’s body field. The original section’s field is unaffected.

A shallow copy copies field values, including references to other objects. A deep copy also copies the mutable objects that need to be independent. This implementation makes a deep copy of the campaign’s mutable section data while safely sharing immutable string values. Deep copying does not mean duplicating every immutable value.

We can check the result immediately after the copy and edit calls:

System.out.println("Template: " + template);
System.out.println("Copy: " + october);

The output shows that only the copied campaign changes:

Template: Monthly update | [News: Add this month's news, Events: Add upcoming events]
Copy: October update | [News: Our new store opens Friday, Events: Add upcoming events]

The same copying rule applies when the original campaign is first constructed. The constructor copies the supplied sections instead of retaining the caller’s mutable section instances. After construction, section(index) intentionally returns one of the campaign’s own sections so the editor can modify it. The campaign is mutable; the guarantee is that its copy owns different mutable sections.

This implementation fits a list of sections containing strings. If sections later contain mutable attachments or other nested data, their copy constructors must define how to copy that data too. Resources such as open connections should not be duplicated simply because another field is copied. Cyclic references also need additional handling to avoid copying the same objects indefinitely.

4. Running and Checking the Example

The source directory contains Campaign.java and PrototypeDemo.java. The demo runs the successful duplicate operation, checks the returned references and then demonstrates an incorrect shallow list copy. Use JDK 17 or later; no additional library is required.

From the repository root, compile and run the example:

javac -d out src/main/java/com/howtodoinjava/patterns/creational/prototype/*.java
java -cp out com.howtodoinjava.patterns.creational.prototype.PrototypeDemo

4.1. Checking Independent Copies

After printing the two campaigns, the demo compares their references. Java’s != operator checks whether two references identify different objects. The demo also checks that the sender value is retained:

System.out.println("Different campaigns: " + (template != october));
System.out.println("Different sections: " +
        (template.section(0) != october.section(0)));
System.out.println("Sender retained: " +
        template.getSender().equals(october.getSender()));

Campaign another = template.copy();
System.out.println("Another copy: " + another.section(0).getBody());

These checks produce:

Different campaigns: true
Different sections: true
Sender retained: true
Another copy: Add this month's news

The first two results confirm that the campaign and its first section have different identities. The sender comparison checks equal content rather than identity, because the sender should keep the same value. Finally, another copy of template still contains the original News text. Editing october has not changed the starting configuration used for subsequent copies.

4.2. Why Copying Only the List Is Not Enough

A new list gives us a separate collection, but its elements may still be shared. To see the difference, create a fresh section and copy only the containing list with the ArrayList collection constructor:

List<Campaign.Section> originalSections = new ArrayList<>();
originalSections.add(new Campaign.Section("News", "Original text"));

List<Campaign.Section> copiedList = new ArrayList<>(originalSections);
copiedList.get(0).setBody("Changed through copied list");

System.out.println("Different lists: " + (originalSections != copiedList));
System.out.println("Same section: " +
        (originalSections.get(0) == copiedList.get(0)));
System.out.println("Original section: " + originalSections.get(0).getBody());

The output exposes the shared element:

Different lists: true
Same section: true
Original section: Changed through copied list

The constructor creates a list containing the same element references. Adding or removing an element from copiedList would change only that list, but calling setBody() changes the Section instance that both lists contain. This is why Campaign.copySections() creates each section separately. Copy the mutable elements as well as the collection when each copy must support independent element edits.

5. Choosing a Java Copying Approach

The Prototype pattern describes creating an object from an existing object’s state. It does not require a particular Java API. A copy constructor and a named copy method are one approach; Java also provides Object.clone(), with different rules.

5.1. Copy Constructors and Object.clone()

A copy constructor uses ordinary construction and makes the copying policy visible in the class. Our copy() method gives clients one operation to call and keeps the constructor itself private. The class can validate values, copy nested data and decide which immutable values to retain.

The JDK’s Object.clone() documentation specifies a field-for-field copy. For a reference field, the copied value is the reference; the referenced object is not also cloned. Consequently, calling super.clone() alone on a class with mutable sections would not provide the independence demonstrated above.

The Cloneable interface marks a class as supporting that field-for-field operation. It does not declare a clone() method. A class using this mechanism typically exposes an overridden clone() method and performs any necessary copying of mutable fields itself. Without Cloneable, Object.clone() throws CloneNotSupportedException.

Our Campaign does not implement Cloneable because it never calls Object.clone(). It creates the copy through constructors. Implementing Prototype does not require implementing Cloneable. The constructor-based approach also lets each new campaign initialize its final list field with a separate list. It does not need to replace that field after construction.

5.2. When a Prototype Registry Helps

An application may offer several prepared campaigns, such as a newsletter, a product announcement and an event invitation. A prototype registry stores those starting objects under names so the client can choose one without reconstructing its configuration.

The important part is to copy the selected prototype before editing it. Using the existing template variable, a small registry could look like this:

Map<String, Campaign> templates = Map.of("newsletter", template);
Campaign draft = templates.get("newsletter").copy();
draft.setSubject("November update");

Here, get() retrieves the stored prototype and copy() returns a separately editable campaign. Editing the value returned by get() directly would change the stored prototype itself.

A registry is useful when selection by name is part of the feature; it is unnecessary when the client already has the campaign it wants to duplicate. An unknown name returns null from get(), so production lookup code must handle that result before calling copy().

The source folder includes RegistryDemo, which prints the original and copied subjects so this behavior can be checked independently.

6. Frequently Asked Questions

Copying rules determine whether two campaigns can be edited independently. Field modifiers, performance and alternative creation patterns raise separate questions when applying those rules to another class.

6.1. Does a final Field Make Its Value Immutable?

No. A final reference field cannot be reassigned after initialization, but the object it refers to may still be mutable. In Campaign, the sections field always refers to the same list, while its section bodies can change. The Java Language Specification distinguishes a fixed reference from the state of the referenced object. Independent copies depend on the copying implementation, not just the presence of final.

6.2. Is Prototype Faster Than Creating an Object With a Constructor?

Not necessarily. Copying can avoid repeating expensive work when the original object already holds reusable results, but copying a large object graph also takes time and memory. Our implementation calls constructors and copies every section; it makes no performance claim. Choose it for the duplicate-campaign behavior, and measure the actual application before choosing a copy strategy for speed.

6.3. How Does Prototype Differ From Builder and Factory?

Prototype starts from an existing object’s state. Builder collects construction values or steps to create an object, while a factory encapsulates the creation decision behind an operation. These approaches can coexist. An application might build an initial campaign and later use it as a prototype, but it does not need all three patterns for a simple copy feature.

7. Conclusion

Use Prototype when a new object should begin with an existing configuration. Define the copy operation around the changes the application must allow: share immutable values, copy the mutable data that needs independence, and verify that editing the result leaves the original unchanged.

Happy Learning!

The complete example is available in the GitHub source folder.