Object relationships: links, sharing and ownership

Choose association, shared aggregation or composition from a stated object-lifetime contract. Relationships and copying · Object-oriented programming.

You remove a song from one playlist and someone warns that every other playlist will lose it too. Another diagram calls a private field “composition” without saying who owns the object. Before choosing an arrow, ask what the application promises about identity, sharing and lifetime.

Start with the links

An object is one instance with its own identity. A reference lets another object find it. Two references can identify the same object without copying it. In the scene, each playlist contains a reference to one catalog Song. Follow the links before reading the diamonds.

An association records a relationship between objects: a playlist knows a song, or a reviewer knows an episode. It does not, by itself, promise exclusive ownership, copying, or deletion. An arrowhead can show which side holds a reference to the other. A line without arrowheads need not claim that either side holds one.

Shared aggregation adds a whole/part interpretation, conventionally a hollow diamond at the whole. Its precise meaning depends on the model. Here we explicitly choose independently cataloged Songs that may appear in several Playlists. Removing one membership leaves the Song available elsewhere. We could draw plain associations and state the same sharing contract in words.

Do not turn “has a field” into a complete ownership proof. A field can reference a shared catalog item, a uniquely owned part, or a temporary collaborator. The declarations may look similar while the requirements differ. Decide what the link means before selecting a UML symbol.

One whole, a different promise

Now model an Episode and its opening Cue. Our requirement says a Cue is an exclusive logical part of one Episode, cannot simultaneously belong to another Episode, and is treated as deleted by the application (no longer listed or usable) when its owning Episode is deleted. We call that logical deletion: the application stops using the object, whether or not memory is reclaimed. Those requirements justify composition, shown with a filled diamond at the whole.

The diamond describes the domain, not a garbage-collector instruction. Suppose a reviewer saved a reference to the Cue (an alias) before the Episode was deleted. The catalog no longer lists the Episode, so the domain says the Cue is gone, yet that saved reference still reaches the same object. Deleting from the domain and freeing memory are separate events, and the program must enforce its own editing rules. The diagram does not automatically prevent an accidental alias, revoke an exposed reference, or choose a collection time.

Composition also does not mean a part can never be moved. A model may permit detaching a part before deleting its old whole and assigning it to a new whole. The important restriction is the ownership rule at a given time. Our tiny Episode example does not expose a transfer operation.

Read the code and the contract together

These complete examples demonstrate sharing. a and b hold the same Song reference; neither Playlist constructor copies the Song. Java == and Python is test identity here. The output is true in Java and True in Python. This says nothing about exclusive ownership because our stated catalog policy deliberately permits sharing.

class Main {
    static final class Song {
        String name;
        Song(String name) { this.name = name; }
    }
    static final class Playlist {
        Song song;
        Playlist(Song song) { this.song = song; }
    }
    public static void main(String[] args) {
        Song catalog = new Song("Lark");
        Playlist a = new Playlist(catalog);
        Playlist b = new Playlist(catalog);
        System.out.println(a.song == b.song);
    }
}

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

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

catalog = Song("Lark")
a = Playlist(catalog)
b = Playlist(catalog)
print(a.song is b.song)

Try two edits. Setting catalog.name = "Wren" changes the one shared Song, so a.song.name and b.song.name both read Wren. Setting catalog = new Song("Kite") in Java, or catalog = Song("Kite") in Python, only moves the local variable; a.song and b.song still hold the Wren Song, and a.song is b.song stays true (Java == true). Mutating a target and rebinding a reference are different operations. The scenes attach and detach by assigning song, so the examples above leave that field non-final.

To keep a Cue exclusive, keep it private and never hand it out. In Java, a private Cue field plus no method that returns it makes the compiler reject access from any other top-level class (classes nested in the same file can still see private members). The scene's shows.episode.cue = null; stands for the Episode's own delete routine, which would be a method inside Episode. In Python, a leading underscore (self._cue) only signals the intent; nothing stops outside code from reading it, so the rule must be kept by the team. If Episode must show cue information, return a small value such as the cue text, not the Cue object. Also write down whether sharing, transfer and deletion are allowed.

Recap

• A stored reference can point to an existing object without creating a copy.
• Shared aggregation needs a stated convention; composition adds exclusive whole/part lifecycle responsibility.
• Logical deletion and runtime memory collection are separate concerns.
• Removing a song from one playlist removes that playlist’s link only; the Song and every other playlist’s link stay.
• Editing the shared Song shows through every holder, but reassigning one variable moves only that variable.
• A saved reference keeps a logically deleted part reachable.
• Keep a part exclusive by never handing it out: Java checks this, Python leaves it to the team.

Check your understanding, then continue to shallow and deep copy to choose which links an edit must isolate. Practise reference rewiring in Linked List Fundamentals, where changing a link is different from mutating the node it reaches.