State Pattern

The obvious way to make getEta() and getDirections() depend on the transport mode is to store the mode as an enum field and branch on it, inside each method, with a switch statement.

This works. DirectionService(TransportMode.CYCLING).getEta() returns 5, getDirections() returns "Take the bike lane," and adding a setMode() method lets the same service object be reused for a different mode later. For four transport modes and two methods, this is entirely readable code — nobody would flag it in review.

The trouble shows up the moment a fifth mode needs to be added, or a third method. Every method that cares about transport mode needs the exact same four-way (soon five-way) branch, copy-pasted in. getEta() and getDirections() already duplicate the same switch structure once; a real navigation service would also need fare estimates, calorie estimates, and route polylines, and every one of them would need this same switch statement written in again.

Worse, adding a mode means going back into every existing method and adding a new case to each one — getEta(), getDirections(), and anything written afterward. It is entirely possible to correctly add a case to three of four methods and simply forget the fourth, and nothing about the code flags that as wrong; it just silently keeps hitting the old default or throwing on the new mode wherever the case was missed.

enum TransportMode { WALKING, CYCLING, CAR, TRAIN }

class DirectionService {
    private TransportMode mode;

    DirectionService(TransportMode mode) {
        this.mode = mode;
    }

    void setMode(TransportMode mode) {
        this.mode = mode;
    }

    int getEta() {
        switch (mode) {
            case WALKING: return 10;
            case CYCLING: return 5;
            case CAR:     return 2;
            case TRAIN:   return 3;
            default:      throw new IllegalStateException();
        }
    }

    String getDirections() {
        // the SAME four-way branch, again
        switch (mode) {
            case WALKING: return "Directions for walking";
            case CYCLING: return "Take the bike lane";
            case CAR:     return "Directions for driving";
            case TRAIN:   return "Directions for the nearest station";
            default:      throw new IllegalStateException();
        }
    }
}

// Adding a fifth mode means editing getEta() AND getDirections() AND
// every method written after this one -- and it is easy to update three
// out of four methods correctly and never notice the fourth was missed.

Look closely at what actually belongs together. "Walking" behavior — its ETA of 10 minutes, its directions string — is one coherent idea, not something that should live as one case scattered across several unrelated switch statements. The fix is to give each transport mode its own class, holding all of its own behavior, with every mode implementing one shared interface so DirectionService can treat all of them identically.

That is the State pattern: extract each behavioral case into its own class implementing a shared contract, and have the object that used to branch on a field instead hold a reference to the current state object and simply delegate every call to it.

The shared contract, TransportationMode, declares both operations every mode must be able to answer. Each old switch case becomes its own small class implementing that interface — Walking, Cycling, Car, Train — each one holding just its own ETA and its own directions string, with nothing about any other mode visible inside it.

DirectionService itself changes shape completely. Instead of a TransportMode enum field and two switch statements, it holds a single TransportationMode reference and delegates every call to whichever object that reference currently points at. getEta() becomes a single line — return mode.getEta(); — with zero knowledge of which modes exist or how many there are. The class that used to be the one place with a wrong-mode risk no longer contains a single conditional.

interface TransportationMode {
    int getEta();
    String getDirections();
}

class Walking implements TransportationMode {
    public int getEta()           { return 10; }
    public String getDirections() { return "Directions for walking"; }
}

class Cycling implements TransportationMode {
    public int getEta()           { return 5; }
    public String getDirections() { return "Take the bike lane"; }
}

// Car and Train follow the identical shape -- each mode's ETA and
// directions logic now live together, in one place, instead of being
// scattered across several switch statements.

class DirectionService {
    private TransportationMode mode; // holds the CURRENT mode object, not an enum

    DirectionService(TransportationMode mode) {
        this.mode = mode;
    }

    void setMode(TransportationMode mode) { // swap the active mode object
        this.mode = mode;
    }

    int getEta()           { return mode.getEta(); }         // pure delegation, no switch
    String getDirections() { return mode.getDirections(); }  // same delegation, zero duplication
}

The real test of this design is adding a new transport mode and seeing exactly what has to change.

First, confirm the refactored version behaves identically to the original. Constructing DirectionService with a Cycling object and calling getEta() returns 5, exactly as before; calling setMode(new Car()) swaps the active mode at runtime, and the very next getEta() call returns 2, using the same service object.

Now add a fifth mode: flights. In the switch-statement version, this meant editing getEta(), editing getDirections(), and editing every future method the same way. In this version, it means writing exactly one new class — Airplane, implementing TransportationMode — and nothing else. DirectionService is not opened, not recompiled around new logic, not touched at all.

The failure mode from the naive version, where a developer might correctly update three methods and forget a fourth, is now structurally impossible: neither getEta() nor getDirections() has any way to even reference which modes exist, so there is nothing left to forget. This is the practical payoff of the State pattern — the set of possible states can grow indefinitely without the object that delegates to them ever needing a matching edit.

public class Main {
    public static void main(String[] args) {
        DirectionService service = new DirectionService(new Cycling());

        System.out.println(service.getEta());          // 5
        System.out.println(service.getDirections());   // "Take the bike lane"

        service.setMode(new Car());                     // swapped, at runtime -- same service object
        System.out.println(service.getEta());          // 2
    }
}

// Adding flight support -- the entire diff, DirectionService untouched:
class Airplane implements TransportationMode {
    public int getEta()           { return 90; }
    public String getDirections() { return "Directions to the nearest airport"; }
}
// service.setMode(new Airplane());

Stateless mode objects like Walking and Cycling hold no data specific to any one DirectionService — a single shared Walking instance could safely serve every DirectionService in an entire application at once, avoiding repeated allocation for something that never changes. That stops being safe the moment a state needs to hold data specific to one particular context, such as how long the service has been in that mode — at that point, sharing one instance across multiple contexts becomes a real, hard-to-trace bug, since two unrelated services would end up reading and overwriting each other's data through the same shared object.

interface PlayerState {
    void pressPlay(MediaPlayer player);
}

class StoppedState implements PlayerState {
    public void pressPlay(MediaPlayer player) {
        System.out.println("Starting playback");
        player.setState(new PlayingState()); // the STATE decides the transition
    }
}

class PlayingState implements PlayerState {
    public void pressPlay(MediaPlayer player) {
        // already playing -- deliberately does nothing
    }
}

class MediaPlayer {
    private PlayerState state = new StoppedState();
    void setState(PlayerState state) { this.state = state; }
    void pressPlay() { state.pressPlay(this); } // caller just says "play"
}