In Java, what are the trade-offs of implementing a State machine with an enum versus separate state classes (or a sealed interface)?

## Setup The State pattern needs: a **State** abstraction, one implementation per **concrete state**, and a **context** holding the current state. Java offers three idiomatic encodings, each with different ergonomics. To choose well you need to know what each gives and costs. ## Option 1 — `enum` with per-constant method bodies A Java `enum` is more than a list of names: each constant can **override abstract methods** with a constant-specific body. That lets an enum *be* a state machine. ```java enum Light { RED { Light next() { return GREEN; } }, GREEN { Light next() { return YELLOW; } }, YELLOW { Light next() { return RED; } }; abstract Light next(); } ``` **Pros** - **Compact** — the whole machine lives in one file, no extra classes. - **Type-safe & closed** — the set of states is fixed and known at compile time; a `switch` over the enum can be checked for exhaustiveness, and you can't invent an illegal state value. - **Singletons for free** — each constant is a single shared instance, so states with no per-instance data needn't be re-allocated. - **Serialization / `valueOf` / `name()`** built in, handy for persisting the current state. **Cons** - **No per-instance state** — every `RED` is the same object; an enum constant can't carry instance-specific data (e.g. a timestamp unique to *this* occurrence of the state). - **No constructor arguments per use-site** — you can't parameterize a state when you transition into it. - **Awkward when behavior is large** — big method bodies inside enum constants get unwieldy. Use it for: small, **fixed** machines whose states are essentially **stateless** strategies of behavior (traffic light, simple workflow, parser modes). ## Option 2 — separate classes behind an interface The classic GoF encoding: `interface State { ... }` with `class OpenState`, `class ClosedState`, etc. **Pros** - **Per-state data** — each state object can hold fields and be constructed with arguments (`new Retrying(attempt, backoff)`). - **Rich behavior** — large, complex per-state logic lives in its own class with its own helpers. - **Extensible** — add a state by adding a class (Open/Closed principle), no central edit. **Cons** - **Boilerplate** — many small files. - **Open set** — the compiler doesn't know all implementations, so `switch`/`instanceof` chains need a default and aren't exhaustiveness-checked. - **Allocation** — you typically `new` states on transition (usually negligible, but real for hot paths). Use it for: large machines, states that carry data, or behavior too big for enum constants. ## Option 3 — `sealed interface` + record/class implementations (modern Java) A **sealed** interface (Java 17+) declares a *closed* set of permitted implementations. It combines the best of both: ```java sealed interface Conn permits Open, Closed {} record Open(long sessionId) implements Conn {} record Closed() implements Conn {} ``` **Pros** - **Closed set like an enum** → `switch` expressions are **exhaustive without a default**, and the compiler errors if you add a state and forget a branch. - **Per-state data like classes** → records can carry fields (`Open` holds a `sessionId`). - **Pattern matching** — `switch (conn) { case Open o -> ...; case Closed c -> ...; }` reads cleanly and binds the data. **Cons** - Requires modern Java (17+ for sealed; later for full pattern-matching ergonomics). - Still more verbose than a tight enum for the truly trivial case. Use it for: machines that want both exhaustiveness *and* per-state data — often the best default in current Java. ## Cross-cutting concerns (all three) - **Transition placement** — decide whether the state or the context owns `next`/`setState`. Enums often return the next constant; class/sealed encodings often `return new NextState(...)`. - **Thread-safety** — if the context's current-state field is mutated concurrently, publish it safely (e.g. `volatile`, a lock, or an immutable swap via `AtomicReference`). Immutable states (enums, records) make this much easier because the state objects themselves can't be corrupted; only the reference needs safe publication. - **Persistence** — enums serialize by `name()` trivially; class/sealed states need an explicit mapping to/from a stored discriminator. ## Decision summary - Few, fixed, **stateless** states, modest behavior → **enum**. - States need **their own data** or **large** behavior, set may grow → **classes**. - Want **exhaustiveness + per-state data + pattern matching** → **sealed interface** (modern default).