Prototype helps when a preconfigured object is easier to copy than to rebuild from scratch.

Create new objects by copying an existing prototype rather than instantiating classes directly.

GoF catalog Which pattern when Previous: Builder Pattern in Java Next: Factory Method vs Abstract Factory vs Builder

Intent

What the pattern is trying to do

Create new objects by copying an existing prototype rather than instantiating classes directly.

Problem

What force creates the need

Object creation is expensive, configuration-heavy, or easiest to express through copying a preconfigured template.

Solution

How the pattern responds

Keep a prototype object and clone or copy it when new similar objects are needed.

Structure

How the moving parts fit together

A prototype instance exposes a copy or clone pathway, and clients create new objects from that existing configured exemplar.

Java Example

Java example in the Order Management domain

Prototype Pattern in Java example

package org.javaomnibus.ecommerce.gof.creational;

public record NotificationTemplate(String subject, String body) {
    public NotificationTemplate copyWithSubject(String newSubject) {
        return new NotificationTemplate(newSubject, body);
    }
}

public final class TemplateCatalog {
    private final NotificationTemplate orderConfirmed =
        new NotificationTemplate("Order confirmed", "Your order has been accepted.");

    public NotificationTemplate orderConfirmedForPriorityCustomer() {
        return orderConfirmed.copyWithSubject("Priority order confirmed");
    }
}

Code Walkthrough

Step by step

The catalog keeps a configured prototype ready to copy.
New instances are derived from that prototype rather than built from scratch repeatedly.
The pattern is most useful when configuration reuse is the real pressure.
In modern Java, explicit copy operations are usually clearer than old-style clone mechanics.

When To Use

Where this pattern helps

When preconfigured templates are reused frequently
When copying is cheaper or clearer than reconstructing from raw configuration each time

When Not To Use

When a simpler design is better

When object construction is simple and cheap
When copying semantics are ambiguous or risky due to deep mutable state

Trade-Offs

What this pattern costs

Copy semantics can be subtle with mutable object graphs
Teams may overcomplicate creation if the cloning pressure is weak

Modern Relevance

How this fits today

Prototype is less visible in everyday Java than Factory or Builder, but it still matters where template copying, snapshot duplication, or preconfigured object reuse are central.

Common Misuse

Where teams get it wrong

Relying on shallow copies when the domain really needs explicit deep-copy or immutable reconstruction is a common source of subtle bugs.

Related Patterns

Compare with nearby choices

Builder Singleton GoF cheatsheet How to spot patterns in real code