Defensive Copy in the Constructor

Before You Start

Check each box you can do from memory. A box you cannot check yet is not a problem; it points you to a quick refresher, not a grade.

• I can explain the difference between copying a reference and copying the object it points to.
• I can identify which fields in a class need defensive copying (mutable reference types) versus which do not (primitives and immutable types like String). See Immutable Fields Need No Defensive Copy.
• I can call an accessor on an object and pass its return value to a constructor.
• I can read a class definition and recognize which fields are composed (owned) versus which are primitives. See Declaring and Initializing a Class-Type Field.

What You Need To Walk In With

You need to know that assigning a reference copies the pointer, not the object it points to, and that private visibility protects the field name from outside code but does not prevent outside code from mutating the object the field refers to. You also need to know how to call an accessor and pass its return value to a constructor. Once those two ideas are in place, the defensive copy pattern is a single line of consequence that follows directly.

You can: identify which fields in a class need defensive copying (mutable reference types) versus which do not (primitives and immutable types like String), state the two requirements a contained type must meet for the new-from-data pattern to work, write a correct defensive copy in a constructor given a class with mutable composed fields and their accessors, and write a short test that reveals the defect when the copy is omitted.

Try this first

You are given the following skeleton. Predict what gets printed before revealing the answer.

class Address {
    private String city;
    Address(String city)    { this.city = city; }
    void    setCity(String c) { this.city = c; }
    String  getCity()         { return city; }
}

class Customer {
    private Address address;
    Customer(Address a) {
        this.address = a;      // direct assignment, no copy
    }
    String getCity() { return address.getCity(); }
}

// In a main method:
Address home = new Address("Cheney");
Customer c   = new Customer(home);
home.setCity("Spokane");
System.out.println(c.getCity());

Write down your prediction, then reveal the answer.

How it works

The problem in one diagram

After this.address = a;

home ──────────────────┐
                       ▼
                 [ Address: "Cheney" ]
                       ▲
c.address ─────────────┘

Calling home.setCity("Spokane") changes the shared object.
Both home and c.address now see "Spokane".

After this.address = new Address(a.getCity());

home ──────► [ Address: "Cheney" ]   (caller's copy)

c.address ─► [ Address: "Cheney" ]   (Customer's private copy)

Calling home.setCity("Spokane") changes only the first object.
c.address still sees "Cheney".

The canonical pattern (S20.Lab3.Book)

The Lab 3 Book class holds a Publisher as a composed field. Its primary EVC does this:

this.pub = new Publisher(pubs.getPubName(), pubs.getPubCity());

pubs is the constructor parameter. The class reads pubName and pubCity from pubs through its public accessors, then passes those values to Publisher’s own constructor to build a new object. After this line runs, Book.pub points to an object that no caller holds a reference to.

Two requirements

For the new-from-data pattern to work, the contained type must satisfy both conditions:

If the contained type offers neither accessors nor a suitable constructor, you may be tempted to call clone(). That approach has well-documented problems (Bloch, Effective Java, Item 13): clone returns Object, requiring an unchecked cast, and a broken or shallow clone in a subclass silently breaks your copy. Adding accessors and a copy constructor to the contained type is the preferred fix.

Copy constructors

A copy constructor takes an instance of its own type and copies all needed state:

// Copy constructor for Publisher
public Publisher(Publisher other) {
    this(other.getPubName(), other.getPubCity());
}

Callers can then write:

this.pub = new Publisher(pubs);

This is the form Bloch recommends (Effective Java, Item 13) as a cleaner alternative to clone.

Quick check

Worked example

Predict, then check

A class Event has fields title (String, immutable) and location (an Address, mutable). The goal is to write a defensive constructor for Event.

Step 1. Identify which fields are mutable reference types. String is immutable, so title needs no copy. Address is mutable, so location does.

Step 2. Confirm Address satisfies both requirements. It has getStreet() and getCity() and a constructor Address(String street, String city). Both requirements are met.

Step 3. Write the constructor:

class Event {
    private String  title;
    private Address location;

    public Event(String title, Address location) {
        this.title    = title;                                          // String: immutable, direct assign OK
        this.location = new Address(location.getStreet(),              // Address: mutable, copy required
                                    location.getCity());
    }
}

Step 4. Verify the fix. After the constructor returns, Event.location points to an object no caller holds. Calling setCity(...) on the original Address does not affect the Event.

Predict: After event.location = new Address(loc.getStreet(), loc.getCity()); runs, what is the reference count on the caller’s Address object?

Common misconceptions

this.pub = pubs;                                                        // assign caller ref
this.pub = new Publisher(this.pub.getPubName(), this.pub.getPubCity()); // then overwrite

Quick check

List<Address> copy = new ArrayList<>();
for (Address a : addresses) {
copy.add(new Address(a.getStreet(), a.getCity()));
}
this.locations = copy;

Formal definition and interface contract

The pattern is grounded in Bloch, Effective Java 3rd edition, Item 50 (“Make defensive copies when needed”):

“You must program defensively, with the assumption that clients of your class will do their best to destroy its invariants.”

Item 50 specifically addresses the constructor case:

“To protect the internals of a Period instance from this sort of attack, it is essential to make a defensive copy of each mutable parameter to the constructor.”

Item 13 (“Override clone judiciously”) explains why copy constructors and static factories are preferred over clone:

“A fine approach to object copying is to provide a copy constructor or copy factory.”

The Java 25 API specification does not mandate defensive copying, but the java.util.Date documentation warns that Date is mutable and callers should be aware of aliasing. The general principle applies to any mutable type a class holds by composition.

Mental model

Think of a field as a name tag, not a container. When you write this.pub = pubs;, you are pinning your name tag onto the caller’s object. Both you and the caller can reach that object. When you write this.pub = new Publisher(pubs.getPubName(), pubs.getPubCity());, you are building your own separate object and pinning your name tag to that. The caller still has their object; you have yours. Outside code cannot reach yours because nobody else holds a reference to it.

Connections

Within CSCD 211: Element-by-Element Array Copy extends this pattern to the return direction. Immutable class design shows how to eliminate the need for defensive copying by making the contained type incapable of mutation.

Looking back: Immutable Fields Need No Defensive Copy established why two references to the same object can cause unexpected behavior. Constructor copy is the fix applied at construction time.

Looking ahead: After learning constructor copy and getter copy together, you have the tools to reason about encapsulation in terms of object graphs, not just field visibility. That reasoning recurs in every topic that involves shared mutable state: collections, generics, and concurrent programming.

Go Deeper (optional)

None of what follows is needed to write correct defensive copies. If the code above is solid, you are done. This section is for when you want to know where the idea fits in the larger map.

Why clone is broken by design. Bloch devotes Item 13 of Effective Java to this question, and the answer spans several layers. Object.clone returns Object, so every call requires an unchecked cast. The Cloneable interface does not declare clone, so there is nothing to put in a type signature. And because clone is inherited, a subclass can override it shallowly or incorrectly, and your code silently receives a broken copy with no compiler warning. Reading Item 13 in full is one of the most instructive 20 minutes in Java because it shows what happens when a feature is designed without a consistent contract.

The function-object idea behind copy constructors. A copy constructor that takes Publisher(Publisher other) and reads other.getPubName() is an example of treating the type as data: you extract what you need and build a new instance. This same idea is the Strategy pattern (passing behavior as an object) and the simplest form of a first-class function. Recognizing it here makes the Strategy pattern easier to understand when it appears by name later.

Aliasing in other languages. The aliasing problem is not Java-specific; it appears in any language with mutable reference semantics. Python, Go, and C++ with raw pointers all have the same hazard. Rust’s borrow checker enforces the absence of aliasing mutations at the type-system level, making the problem structurally impossible in safe Rust. If you ever look at a Rust ownership diagram, it is the same two-arrow picture from the diagram above, made into a compile-time rule.

Where this appears in professional code. In enterprise Java, defensive copying shows up constantly in value objects: an Order copying a ShippingAddress, an Invoice copying LineItem data, a configuration object copying a mutable Properties map. Knowing the pattern by name (“defensive copy,” “copy constructor”) and being able to cite Bloch Item 50 is a concrete talking point in technical interviews, because it shows you think about invariant preservation, not just syntax.

Practice

Level 1

You are given:

class Point {
    private int x, y;
    public Point(int x, int y)    { this.x = x; this.y = y; }
    public int getX()              { return x; }
    public int getY()              { return y; }
    public void translate(int dx, int dy) { x += dx; y += dy; }
}

class Circle {
    private Point center;
    private int   radius;
    // TODO: write this constructor
    public Circle(Point center, int radius) { ... }
}

Write the body of Circle’s constructor so that mutations to the caller’s Point after construction do not affect the Circle’s center.

public Circle(Point center, int radius) {
    this.center = new Point(center.getX(), center.getY());
    this.radius = radius;
}

Level 2

The stem below has a constructor that defensively copies a Publisher. Explain what happens at runtime if the developer instead wrote this.pub = pubs;, then trace through a small test to show the problem.

// Current (correct) version in S20 Lab 3:
public Book(String title, Publisher pubs, int year) {
    this.title = title;
    this.pub   = new Publisher(pubs.getPubName(), pubs.getPubCity());
    this.year  = year;
}

Write the broken version and then the test that reveals the defect.

public Book(String title, Publisher pubs, int year) {
    this.title = title;
    this.pub   = pubs;              // alias -- not a copy
    this.year  = year;
}

Publisher p    = new Publisher("EWU Press", "Cheney");
Book      b    = new Book("Data Structures", p, 2024);
p.setPubCity("Spokane");                      // mutate after construction
System.out.println(b.getPub().getPubCity());  // prints "Spokane" -- wrong

Level 3

A class Schedule holds a List<Event> as a composed field. Each Event is mutable. Write a constructor for Schedule that defensively copies the list so that:

1. Adding or removing events from the caller’s list after construction does not affect the Schedule.
2. Mutating an individual Event object from the caller’s list does not affect the Schedule’s copy.

Assume Event has accessors getTitle() and getDate() and a constructor Event(String title, LocalDate date). LocalDate is immutable.

class Schedule {
    private List<Event> events;

    public Schedule(List<Event> events) {
        List<Event> copy = new ArrayList<>();
        for (Event e : events) {
            copy.add(new Event(e.getTitle(), e.getDate()));   // deep copy: new Event per element
        }
        this.events = copy;
    }
}

Check Yourself

Close the notes and answer each one from memory, then reveal it. Pulling an idea back from memory is one of the strongest ways to make it stick.