Shallow and deep copy: trace the mutable boundary

Inspect object identities before choosing how to duplicate a playlist for independent edits. Relationships and copying · Object-oriented programming.

You duplicate a playlist before editing it, then a song name changes in both versions. The word “copy” hid an important question: which objects did your operation actually duplicate? Follow each reference before choosing the boundary you need.

Name the objects before copying

P0 is a Playlist object. Its songs field refers to list L0, whose first slot refers to mutable Song S0, initially named Lark. The arrows are ordinary references; they do not say who owns whom. This example asks for edit isolation; it does not claim that every real playlist owns its songs exclusively.

Unlike an alias, which creates no object, a shallow root copy creates P1 and copies the root’s fields. Its songs reference still points to L0. You now have two Playlist identities but only one shared list and one shared Song along these paths.

When you change original.songs[0].name, you mutate S0. Following the path from P1 reaches S0 too, so the shallow version observes the changed name. Copying the outer object did not place a boundary around the whole mutable object graph.

Give the edit its own mutable graph

Restart from Lark. Our chosen deep copy creates P1, list L1 and Song S1. Renaming original’s S0 now leaves S1 unchanged. The scene uses a single distinct, acyclic Song leaf so the Java constructor policy and Python’s recursive copying describe the same graph.

These complete examples create the shallow and deep versions before mutating the original. Both print Glow for the shallow view and Lark for the deep view after clearing the two names that denoted the original root.

Python ships generic copy.copy and copy.deepcopy. Java has no universal built-in deep copy: Object.clone() is shallow by default and needs care to override, so a Java deep copy is a constructor or method you write, which makes its boundary your chosen policy.

import java.util.ArrayList;
import java.util.List;
class Main {
    static final class Song {
        String name;
        Song(String name) { this.name = name; }
    }
    static final class Playlist {
        final List<Song> songs;
        Playlist(List<Song> songs) { this.songs = songs; }
        Playlist deepCopy() {
            List<Song> copied = new ArrayList<>();
            for (Song s : songs) copied.add(new Song(s.name));
            return new Playlist(copied);
        }
    }
    public static void main(String[] args) {
        Playlist original = new Playlist(
            new ArrayList<>(List.of(new Song("Lark"))));
        Playlist alias = original;
        Playlist shallow = new Playlist(original.songs);
        Playlist deep = original.deepCopy();
        original.songs.get(0).name = "Glow";
        original = null;
        alias = null;
        System.out.println(shallow.songs.get(0).name);
        System.out.println(deep.songs.get(0).name);
    }
}

import copy

class Song:
    def __init__(self, name):
        self.name = name

class Playlist:
    def __init__(self, songs):
        self.songs = songs

original = Playlist([Song("Lark")])
alias = original
shallow = copy.copy(original)
deep = copy.deepcopy(original)
original.songs[0].name = "Glow"
del original, alias
print(shallow.songs[0].name)
print(deep.songs[0].name)

Equal contents before an edit do not prove shared identity, and different roots do not prove independent descendants. In Java, compare references with == rather than assuming equals answers the same question. In Python, use is when asking whether two paths reach one object.

The immutable name values need not get new identities. Changing a Song’s name field replaces that field’s reference to a string; it does not mutate the string itself. The mutable Song objects, lists and Playlist roots are the boundaries that matter for the edits shown here.

Clear a binding without inventing destruction

Assigning Java null clears the reference held by each declared local variable, while Python del removes each name binding; in both cases, those names no longer refer to the previous root. Neither operation walks through the graph destroying every object once reachable from the original root. The shallow version still reaches L0 and S0. Their references remain valid, so reading Glow is expected.

The scene clears the name by rebinding it to None, where the complete examples use del. It still draws the original root P0 with 0 references and its links unchanged, so List L0 keeps counting P0’s arrow. Drawn is not freed, and the scene does not claim a collection occurred at that instruction. A garbage collector’s timing is a separate issue, and this example has no explicit resource disposal or C++ owning-pointer destruction.

A faded example: only the list is new

Now allocate a new Playlist and a new list, but keep the same Song in both lists. After renaming that shared Song to Glow, replace only the original list’s first slot with a new Song named Mist. Watch which Song the copied list’s slot still reaches after the original slot is replaced.

The new list isolates membership changes. It does not isolate earlier mutation of a shared element. “A list copy” and “a shallow Playlist copy” therefore have different boundaries in this object graph. Always name the object to which the copying operation applies.

In real code, a method that hands out or stores a caller’s playlist is a boundary. Copy only as deep as the edits you expect: a new list protects membership, a copied Song protects names. Copying deeper than needed costs time and can break shared identity you wanted.

Recap

• Assignment preserves root identity; a shallow root copy changes the root while sharing nested references.
• Our deep policy duplicates the mutable descendants needed for independent Song edits.
• A copied list separates membership updates but can still share mutable elements.
• Clearing the original’s variable removes only that reference; objects still reached from a copy stay valid.
• Python’s copy.deepcopy and a Java copy method you write set the boundary, because Java has no universal deep copy.

// Inside Main.main, using the classes above:
Playlist original = new Playlist(
    new ArrayList<>(List.of(new Song("Lark"))));
Playlist listOnly = new Playlist(new ArrayList<>(original.songs));
original.songs.get(0).name = "Glow";
original.songs.set(0, new Song("Mist"));
System.out.println(listOnly.songs.get(0).name);
System.out.println(original.songs.get(0).name);

# Using the classes above:
original = Playlist([Song("Lark")])
list_only = Playlist(list(original.songs))
original.songs[0].name = "Glow"
original.songs[0] = Song("Mist")
print(list_only.songs[0].name)
print(original.songs[0].name)

Check your understanding. Next, equality and hash contracts ask when two different objects should count as the same value. To practise identity and link updates first, try Linked List Fundamentals.