creational
State
Allow an object to alter its behavior when its internal state changes.
Some objects behave completely differently depending on what phase of their lifecycle they're in. An order behaves one way while pending, another while shipped, another once delivered; a media player responds to "play" differently when stopped versus paused. Implemented with flags and conditionals, this becomes a mass of switch (status) blocks repeated in every method, and adding a new phase means editing all of them — fragile and easy to get inconsistent. State pattern gives each phase its own class so behaviour and transitions live together.
A vending machine — idle shows items, has-money accepts selection, dispensing delivers product.
Key Concepts
1
Each state is encapsulated in a class implementing a common state interface, with one method per action the object supports. The context object holds a reference to its current state and delegates every action to it. The elegant part is transitions: a state object decides what state should come next and tells the context to switch, so the logic for "what happens after this" sits inside the state it happens from, not in a central conditional. Adding a new state is writing one new class, and the giant switch statements vanish.
2
It fits objects with distinct lifecycle phases — orders, documents, connections — finite state machines, UI components that move between enabled, loading, and error modes, and game characters cycling through idle, walking, and attacking. The comparison interviewers expect is with Strategy, which is structurally identical: the difference is intent. In State the objects represent stages that know about and transition into each other, and the object changes its own behaviour over time; in Strategy the client picks an independent algorithm and the strategies are unaware of one another. The cost is more classes, which only pays off once the conditional logic is genuinely complex.