Introduction
Builder and Prototype are two more Creational patterns that address object construction from different angles. Builder separates the construction of a complex object from its final representation, so the same construction process can produce different representations. Prototype creates new objects by copying (cloning) an existing object, called the prototype, rather than instantiating a class from scratch. Both patterns avoid the pitfalls of constructors with many parameters or expensive re-initialization.
Cricket analogy: Builder is like a coach assembling a batting order step by step — set opener, set middle order, set finisher — producing different lineups from the same process, while Prototype is like cloning last season's winning XI and tweaking one player instead of re-selecting from scratch.
Explanation
Builder is especially useful when an object requires many optional parameters or must be constructed through a multi-step process (for example, building an HTTP request, a SQL query, or a complex configuration object). Rather than a constructor with ten optional parameters — sometimes called a 'telescoping constructor' anti-pattern — a Builder exposes fluent methods like .set_host(...) or .add_header(...) that each return the builder itself, culminating in a .build() call that produces the finished object. This keeps construction readable and lets the same builder logic assemble different variants.
Cricket analogy: Instead of a single 'select XI' call needing ten optional parameters (extra spinner, extra pacer, extra all-rounder...) — the telescoping-constructor anti-pattern — a selection committee builds fluently: pick openers, then middle order, then bowlers, culminating in a finalized XI announcement.
Prototype solves a different problem: sometimes creating an object from scratch is expensive (e.g., it involves a database query, complex computation, or deep configuration) but a very similar object already exists in memory. Instead of paying that cost again, Prototype clones the existing object — typically using Python's copy.deepcopy for a full deep copy, or a custom clone() method that gives fine-grained control over what gets copied versus shared. The clone can then be tweaked independently of the original.
Cricket analogy: Building a full scouting report on a new player from scratch requires weeks of footage analysis, but if a similar player's report already exists, an analyst clones it and tweaks the specifics — using a full deep copy so editing the new report doesn't corrupt the original player's file.
Example
import copy
# --- Builder: step-by-step construction of a complex object ---
class HttpRequest:
def __init__(self):
self.method = "GET"
self.url = None
self.headers = {}
self.body = None
def __repr__(self):
return f"{self.method} {self.url} headers={self.headers} body={self.body}"
class HttpRequestBuilder:
def __init__(self):
self._request = HttpRequest()
def method(self, method):
self._request.method = method
return self
def url(self, url):
self._request.url = url
return self
def header(self, key, value):
self._request.headers[key] = value
return self
def body(self, body):
self._request.body = body
return self
def build(self):
return self._request
# --- Prototype: clone an existing object instead of rebuilding it ---
class ReportTemplate:
def __init__(self, title, sections):
self.title = title
self.sections = sections # expensive to compute originally
def clone(self):
return copy.deepcopy(self)
if __name__ == "__main__":
req = (HttpRequestBuilder()
.method("POST")
.url("https://api.example.com/orders")
.header("Content-Type", "application/json")
.body('{"item": "book"}')
.build())
print(req)
base_report = ReportTemplate("Q1 Report", ["Summary", "Revenue", "Costs"])
q2_report = base_report.clone()
q2_report.title = "Q2 Report"
print(base_report.title, q2_report.title)
print(base_report.sections is q2_report.sections) # False, deep copyAnalysis
The HttpRequestBuilder methods each mutate the internal _request object and return self, enabling the fluent, chained style shown in __main__. This decouples the 'how to assemble a request' logic from the HttpRequest class itself, and the same builder could be extended to build very different request shapes without changing HttpRequest. In the Prototype example, clone() calls copy.deepcopy, ensuring q2_report.sections is an independent list rather than a reference to base_report.sections — verified by the is check printing False. If a shallow copy.copy had been used instead, mutating q2_report.sections would have also changed base_report.sections, which is rarely the intended behavior for a prototype clone.
Cricket analogy: The selection committee's fluent process — pick openers, returning control, then bowlers, returning control again — mirrors HttpRequestBuilder mutating and returning self; separately, cloning a template bowling attack for a new tour with a true deep clone means editing the field settings doesn't touch the original tour's plan — verified because they're genuinely different documents, not one file referenced twice.
Both patterns reduce coupling to concrete construction logic, but they target different costs: Builder tames the complexity of assembling an object with many parts or optional fields, while Prototype avoids the runtime cost of re-deriving an object that already closely resembles one you have. A frequent point of confusion is thinking Prototype is about defining a class hierarchy from scratch — it is not; it is specifically about copying an existing runtime instance.
Cricket analogy: Builder tames the complexity of picking an eleven with many interdependent roles, while Prototype avoids re-scouting an entire opposition from scratch when a similar team was analyzed last series; a common mistake is thinking Prototype means designing a new 'type' of team from the coaching manual — it doesn't, it's about copying an actual existing scouting report.
Key Takeaways
- Builder separates step-by-step construction of a complex object from its final representation.
- Builder avoids the 'telescoping constructor' problem of too many constructor parameters.
- Prototype creates new objects by cloning an existing instance rather than building from scratch.
- Python implements Prototype cloning via copy.deepcopy or a custom clone() method.
- Deep copy vs shallow copy matters: Prototype clones should typically be independent of the original.
Practice what you learned
1. What problem does the Builder pattern primarily solve?
2. How does the Prototype pattern create new objects?
3. In Python, which function is commonly used to implement a full clone in the Prototype pattern?
4. Why might a shallow copy be problematic for a Prototype clone?
Was this page helpful?
You May Also Like
Singleton and Factory Patterns
Learn how Singleton guarantees a single instance and how Factory Method delegates object creation to a central point.
Design Patterns Overview
An introduction to the Gang of Four design patterns and their three categories: Creational, Structural, and Behavioral.
Encapsulation
How Python conventions for protected and private attributes, plus properties, let classes control access to their internal state.
Classes and Objects
How classes act as blueprints for objects, and the difference between class attributes and instance attributes.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 40 topics