A class whose state is a String.
When an object has a small set of named modes — "open", "closed", "locked" — a String field plus controlled transitions implements a clean state machine.
A state machine is an object that exists in one of several named states at any time. Transitions between states happen only when certain methods are called — and only some transitions are valid from each state.
The simplest AP CSA implementation: a String field stores the current state name; each transition method checks the current state, decides whether the transition is allowed, and updates the field.
On the AP exam, state machines appear in lock/unlock FRQs, traffic-light problems, and account status problems.
State variable plus transition guards.
Each transition method asks "what state am I in?" before changing it.
Door class
public class Door {
private String state; // "open", "closed", or "locked"
public Door() { state = "closed"; }
public void open() {
if (state.equals("closed")) {
state = "open";
}
// can't open from locked or already-open
}
public void close() {
if (state.equals("open")) {
state = "closed";
}
}
public void lock() {
if (state.equals("closed")) {
state = "locked";
}
}
public void unlock() {
if (state.equals("locked")) {
state = "closed";
}
}
public String getState() { return state; }
}
Transition table (in code)
- closed → open via
open() - open → closed via
close() - closed → locked via
lock() - locked → closed via
unlock()
Every other call is ignored. Trying to open a locked door silently fails — the state stays "locked".
String comparison uses .equals()
Never compare state strings with == — that compares references, not contents. Always .equals().
State-machine vocabulary.
Used in lifecycle and mode-based problems.
- State machine — object with named modes and controlled transitions.
- State — current mode.
- Transition — change from one state to another.
- Guard — check that prevents invalid transitions.
- Initial state — state set by the constructor.
- Silent failure — invalid transition ignored without exception.
How state machines are tested.
Transition guards and .equals() dominate.
- Guard each transition. Only allow valid moves.
- String comparison uses
.equals(), never==. - Initial state from constructor. First state determines what's allowed next.
- Silent failure on invalid. Don't crash; leave state alone.
MCQ patterns: trace state after a sequence of calls including invalid ones.
Trace door transitions.
Some calls succeed; some are ignored.
Setup. Door d = new Door(); — state = "closed".
Operations:
d.open(): state is "closed" → transition. State = "open".d.lock(): state is "open"; guard requires "closed" → ignored. State stays "open".d.close(): state is "open" → transition. State = "closed".d.lock(): state is "closed" → transition. State = "locked".d.open(): state is "locked"; guard requires "closed" → ignored. State stays "locked".d.unlock(): state is "locked" → transition. State = "closed".
Final state: "closed".
Why this matters. The locked door correctly resists open() calls. Only the legitimate path (unlock first, then open) works.
State-machine pitfalls.
Most break with == or missing guards.
- Using
==for state comparison. Use.equals(). - Missing transition guards. Every transition fires regardless of state.
- Typos in state names. "closed" vs "Closed" don't match.
- Throwing exceptions on invalid transitions. AP usually wants silent failure.
- No initial state. Field stays null;
.equals()crashes. - Returning the wrong field. getState should return the state string.
State-machine essentials.
Three components.
State Machine Reference
AP Quick Reference| Component | Detail | AP Tip |
|---|---|---|
| State field | private String state | Holds named mode. |
| Initial state | Set in constructor | Never null. |
| Transition method | Guard then assign | .equals() check. |
| Invalid call | Silent skip | State unchanged. |
How to master state machines.
Draw the transition diagram before coding.
Use the three practice tools below this lesson in order:
- MCQ Practice — for each call sequence, trace state at every step; mark invalid calls.
- Java Lab — build Door, then a TrafficLight, then a vending machine. Test all transitions including invalid ones.
- FRQ Practice — sketch the state diagram in the margin first; each arrow becomes a guard in a transition method.
If you can list every valid transition from every state before writing code, the implementation almost writes itself.
Practice — attempt these now.
AP-style assessments aligned to this lesson. Time them.
AP CSA Unit 10 Topic 04 String-Based State Machine FRQ Practice
AP-style topic practice assessment