A class can expose a small, carefully designed interface and still lose control of its own state. The problem appears when the class stores a mutable value that other code can also modify.
Imagine an order object that accepts a list of line items. The constructor validates the list, calculates a total, and assumes the items will now change only through the order’s methods. If the caller still holds the same list, that assumption is false. The caller can modify the list directly, bypassing validation and leaving the order’s cached total inconsistent with its items.
A defensive copy breaks that unwanted sharing. Instead of storing or returning a caller-owned mutable object directly, code copies the data at the boundary where ownership would otherwise be ambiguous.
This article explains how to recognize that problem, where copying helps, where it does not, and how to avoid turning defensive copying into unnecessary work.
Start with ownership, not copying
The useful mental model is ownership: which part of the program is allowed to decide when a mutable value changes?
Consider this simplified pseudocode:
class Order:
constructor(items):
require items is not empty
self.items = items
self.total = sum_prices(items)The constructor checks its input, but self.items and the caller’s items refer to the same mutable list.
items = [book, pen]
order = Order(items)
items.append(laptop)After the append, order.items contains the laptop even though no Order operation approved that change. If order.total was calculated only in the constructor, the object’s fields now disagree.
The important failure is not that a list changed. The failure is that two parts of the program share authority over one mutable object while one of them assumes it has exclusive control.
Copy mutable input when the receiver needs independent state
If Order intends to own its collection, it can copy the input before storing it:
class Order:
constructor(items):
require items is not empty
self.items = copy(items)
self.total = sum_prices(self.items)Now the caller and the order have different list objects. Appending to the caller’s list no longer changes the order.
This is a useful boundary rule:
When a component needs to preserve an invariant over mutable input, do not let unrelated code retain an uncontrolled path to that same mutable state.
Copying is one way to enforce that rule. Other designs can work too, such as immutable values or an explicit ownership-transfer convention. The right choice depends on the language and the contract.
Returning internal mutable state creates the same problem
Protecting only the constructor is incomplete if a method later returns the internal collection directly.
class Order:
method get_items():
return self.itemsA caller can now bypass the order again:
items = order.get_items()
items.clear()The reference escaped through the output boundary rather than entering through the input boundary, but the consequence is the same: external code can mutate state without going through the object’s rules.
If callers only need a snapshot, return a copy:
class Order:
method get_items():
return copy(self.items)If callers need to change the order, provide an operation that expresses that intent:
order.add_item(laptop)
order.remove_item(pen)Those methods can validate the change and update dependent state together.
Shallow copies have a boundary
A common mistake is to assume that copying a collection automatically isolates everything inside it.
Suppose an order stores mutable item objects:
items = [item_a, item_b]
order = Order(copy(items))The two lists are independent, but both lists still contain references to the same item_a and item_b. If another part of the program mutates item_a, the order observes that mutation too.
This is the difference between a shallow copy and a deep copy. A shallow copy duplicates the outer container but continues to share referenced elements. A deep copy recursively duplicates some or all nested mutable data.
Deep copying is not automatically the correct fix. It can be expensive, and object graphs may contain identities or resources that should not be duplicated. A database connection, open file, shared cache entry, or domain entity with meaningful identity is not simply “nested data to copy.”
Instead, decide what must be independent. If line items are immutable value objects, a shallow copy of the list may be sufficient. If the elements themselves are mutable and the order must own independent versions, the design needs a clear policy for copying those elements too.
Copy at the boundary that establishes the contract
Defensive copies are easiest to reason about when they happen at ownership boundaries rather than at arbitrary points throughout the code.
Typical boundaries include:
- constructors or factory functions that retain caller-provided mutable data;
- setters that store mutable values for later use;
- getters that expose internal mutable collections;
- event or message objects that must represent a stable snapshot;
- caches that must not let callers mutate stored values accidentally.
Copying repeatedly inside ordinary calculations often hides the ownership model instead of clarifying it. A developer should be able to answer, “Who owns this value after this call?” without tracing many incidental copies.
For an input boundary, document whether the receiver copies, shares, or takes ownership of the value. For an output boundary, document whether the returned value is a snapshot, a read-only view, or a live mutable reference.
A realistic example: preserving a pricing snapshot
Suppose checkout receives a mutable cart and creates an order. The business requirement is that the submitted order must preserve the items and prices that were accepted at checkout, even if the shopping cart changes later.
Sharing the cart’s item list violates that requirement:
order = Order(cart.items)
cart.remove_item(book)If Order stores the same list, a cart operation can silently rewrite the submitted order.
A stronger design creates an order-owned snapshot:
order_items = []
for cart_item in cart.items:
order_items.append(
OrderItem(
product_id = cart_item.product_id,
quantity = cart_item.quantity,
unit_price = cart_item.current_price
)
)
order = Order(order_items)Here the important idea is larger than copy(list). Checkout deliberately converts mutable cart state into order-owned values. The order can then enforce its own lifecycle independently of the cart.
In production code, the exact representation depends on the domain and language. The example is intentionally small: it demonstrates that defensive copying is about preserving a contract, not mechanically duplicating every object.
Copying does not make concurrent mutation safe
Defensive copying prevents later mutation through a shared reference only after a valid independent copy has been created.
It does not automatically solve races while the copy is being made. If another thread or process can mutate the source concurrently, the copy operation may need synchronization or a source that already provides snapshot semantics. The required mechanism depends on the concurrency model.
Likewise, copying an in-memory value does not provide transaction isolation for data stored elsewhere. A defensive copy is a local ownership technique, not a substitute for database transactions, locks, version checks, or other coordination mechanisms.
Prefer simpler designs when sharing is already safe
Copying every argument and return value is unnecessary.
No defensive copy is usually needed when the value is immutable, when the API intentionally exposes shared mutable state, or when ownership is transferred clearly and the previous owner agrees not to use the value afterward.
For example, an immutable coordinate value can be shared freely because no caller can change it. Copying it merely to follow a blanket rule adds noise without protecting anything.
A read-only view can also be useful when the language or library can enforce it appropriately. A view avoids copying a large collection, but it has different semantics from a snapshot: if the owner changes the underlying collection, the view may reflect those changes. Choose a view only when live observation is part of the contract.
Watch for common failure modes
The first is copying the outer container while forgetting mutable elements inside it. Decide explicitly which levels require independent ownership.
The second is protecting inputs but leaking state through getters, iterators, callbacks, or other outputs. Ownership can escape through any interface that exposes a mutable reference.
The third is using deep copy as a universal repair. Deep copying may duplicate too much, preserve the wrong relationships, or fail for resources that cannot sensibly be copied. Model the required independence instead.
The fourth is copying without a reason. Copies consume memory and CPU, and large data structures can make that cost significant. If mutation cannot violate a contract, copying may provide no benefit.
The fifth is assuming documentation alone enforces ownership. A comment such as “do not modify this list” can be a reasonable convention in some codebases, but it offers weaker protection than an API that makes the unwanted mutation impossible or difficult.
Decide with three questions
When mutable data crosses an interface, ask three questions.
First, who is allowed to mutate this value after the call? If both sides may mutate it, shared state is intentional and the coordination rules should be explicit.
Second, does one side rely on the value remaining unchanged except through its own operations? If so, sharing the mutable object can break that assumption. Copying or immutability can establish the needed independence.
Third, how deep must the independence go? Copy only the outer collection when the elements are safe to share. Copy or convert nested values when their mutation would violate the receiving component’s contract.
These questions turn defensive copying from a habit into a design decision.
Conclusion
Defensive copying is useful when a component must control mutable state but an input or output would otherwise give unrelated code another path to change it.
The core idea is ownership. Copy mutable input when the receiver needs independent state, avoid exposing internal mutable objects when callers should not control them, and remember that a shallow copy isolates only the container itself.
Do not copy by default. Prefer immutable values when they fit, use explicit shared state when sharing is intentional, and consider the cost of large copies. The goal is not to eliminate references. It is to make mutation happen through the boundaries that are responsible for keeping the program’s state valid.