Iterator & Mediator

Iterator: sequential access without exposing internal structure

Java's own Iterator interface (see Iterators & Modification Semantics for its full mechanics) is the pattern itself, already built into the language — but the underlying idea is worth stating explicitly: a collection exposes a way to visit its elements one at a time, without callers needing to know whether it's backed by an array, a linked list, or a tree.

interface Playlist {
    PlaylistIterator createIterator();
}
interface PlaylistIterator {
    boolean hasNext();
    Song next();
}

class ArrayPlaylist implements Playlist { // backed by an array
    private final Song[] songs;
    ArrayPlaylist(Song[] songs) { this.songs = songs; }
    public PlaylistIterator createIterator() {
        return new PlaylistIterator() {
            private int index = 0;
            public boolean hasNext() { return index < songs.length; }
            public Song next() { return songs[index++]; }
        };
    }
}

class LinkedPlaylist implements Playlist { // backed by a linked structure — completely different internals
    private SongNode head;
    public PlaylistIterator createIterator() {
        return new PlaylistIterator() {
            private SongNode current = head;
            public boolean hasNext() { return current != null; }
            public Song next() { Song s = current.song; current = current.next; return s; }
        };
    }
}

void printAll(Playlist playlist) {
    PlaylistIterator it = playlist.createIterator();
    while (it.hasNext()) System.out.println(it.next()); // works identically regardless of internal storage
}

printAll works with either implementation unchanged — it never touches an array index or a linked-node reference directly. This is precisely why Java's collections framework standardizes on Iterator rather than exposing each collection's storage details to every piece of code that needs to loop over it.

Mediator: centralizing object-to-object communication

Without Mediator, N objects that need to coordinate with each other tend toward each holding direct references to every other object they might need to talk to — an O(N²) web of dependencies that's hard to change safely. Mediator introduces one coordinator object that all the others talk to instead of each other.

interface ControlTower {
    void requestLanding(Aircraft aircraft);
    void requestTakeoff(Aircraft aircraft);
}

class AirportControlTower implements ControlTower {
    private boolean runwayOccupied = false;

    public void requestLanding(Aircraft aircraft) {
        if (!runwayOccupied) {
            runwayOccupied = true;
            aircraft.clearedToLand();
        } else {
            aircraft.holdPattern(); // tower decides, aircraft doesn't negotiate directly with other aircraft
        }
    }
    public void requestTakeoff(Aircraft aircraft) { /* similar runway-arbitration logic */ }
    void runwayCleared() { runwayOccupied = false; }
}

class Aircraft {
    private final ControlTower tower; // only knows about the tower, never about other aircraft directly
    Aircraft(ControlTower tower) { this.tower = tower; }
    void requestLanding() { tower.requestLanding(this); }
    void clearedToLand() { /* ... */ }
    void holdPattern() { /* ... */ }
}

No Aircraft ever holds a reference to another Aircraft — every coordination decision (who lands first, who waits) routes through AirportControlTower. Adding a new aircraft means it only needs to know about the tower, not about every other aircraft that might already be in the airspace.

Follow-up questions this topic invites — and their answers

Q: Isn't a Mediator just a god-object that violates Single Responsibility? A: It's a real risk if the mediator accumulates unrelated coordination logic over time — but its one cohesive responsibility (coordinating this specific group of objects) is legitimately singular, unlike a true god-object doing several unrelated things. The tradeoff is deliberate: centralizing coordination logic in one place is often better than scattering N-to-N direct dependencies across every participant, even though it does concentrate complexity into that one class.

Q: How does Mediator relate to Observer — could the control tower notify aircraft of runway status changes using Observer instead? A: Yes, and real implementations often combine them — aircraft could subscribe to the tower's runwayCleared event (Observer) while still routing every request (land, take off) through the tower directly (Mediator). Mediator centralizes coordination decisions; Observer handles broadcasting state changes — complementary, not competing.

Q: Why does Iterator matter for encapsulation specifically, beyond convenience? A: Without it, code that needs to loop over a collection would need direct access to its internal representation (an array's index bounds, a linked list's node-chasing logic) — which means the collection's internal implementation is no longer free to change without breaking every caller. Iterator is what lets ArrayList internally switch its resizing strategy or HashMap change its bucket structure without any code that merely iterates over them needing to change at all.

Q: What's the fail-fast/fail-safe distinction's relevance here? A: It's the same Iterator concept extended with a concurrency contract — see Iterators & Modification Semantics for the full mechanics of how Java's built-in iterators handle (or deliberately don't handle) concurrent modification during traversal.