How does an object change its behavior dramatically depending on its internal state? Think of a vending machine. If it has items in stock and you insert a coin, it lets you make a selection. If it's sold out, it rejects the coin. If you've inserted a coin but haven't chosen an item, pressing a button dispenses the item. The machine's response to the same action (inserting a coin) is completely different based on its current state ("Has Stock," "Sold Out," "Has Coin"). The State Pattern is a clean way to manage this by turning each state into its own object.

🔍 The Discovery

  • Name of the Technology: The State Pattern

  • Original Creator/Institution: A classic software design pattern, famously documented in the 1994 book "Design Patterns: Elements of Reusable Object-Oriented Software" by the "Gang of Four."

  • Year of Origin: circa 1994

  • License: A fundamental, public domain software design concept.

The pattern works by creating separate "state" objects that encapsulate the behavior for a particular state. The main object (the "context," like our vending machine) holds a reference to its current state object. When an action occurs, the context doesn't handle it directly; it delegates the action to its current state object. That state object performs the action and, crucially, can decide the next state for the context. This approach avoids massive, messy if/else or switch statements and makes the object's behavior clean, organized, and easy to extend.

🛠️ Ready for Today: Why This Isn't Just Theory

The State pattern is a powerful way to model objects that behave like "finite-state machines." It's similar to the Strategy Pattern (which we covered in Issue #63), but with a key difference: in the State pattern, the states themselves control the transitions to other states, creating a defined workflow. In the Strategy pattern, the client usually decides which strategy to use.

  • Status: The concept is in the public domain.

  • Implementations: This is a behavioral design pattern, not a library. It's a recipe for structuring code in any object-oriented language.

    • Document Workflows: A document in a publishing system can exist in a Draft state, a Moderation state, or a Published state. In the Draft state, the publish() action might submit it for review, transitioning it to the Moderation state. In the Moderation state, the same publish() action might make it live, transitioning it to Published.

    • Game Character AI: The AI for a video game character can be managed with states. An enemy might be in a Patrolling state. When it sees the player, it transitions to a Chasing state. If it gets close, it transitions to an Attacking state. If its health drops, it might transition to a Fleeing state.

    • Connection Protocols: A network connection object can be in a Connecting state, a Connected state, or a Disconnected state. The behavior of send() or receive() methods would be handled differently by each state object.

💡 Creative Applications (Ideas To Get You Thinking)

Modeling an object's life cycle as a series of explicit states is a powerful way to build robust and predictable systems.

  • Idea 1 (A "Smart" To-Do List Task): Instead of just being "done" or "not done," a task item could be an object managed by the State pattern. It could have states like New, InProgress, Blocked, and Completed. In the InProgress state, a "complete" action moves it to Completed. In the Blocked state, the "complete" action might do nothing. This allows for much richer and more realistic project management logic.

  • Idea 2 (An "Order Fulfillment" System): An e-commerce order can be modeled as a state machine. It starts in a PaymentPending state, moves to Paid, then PreparingForShipment, then Shipped, and finally Delivered. Each state object would be responsible for handling events like "payment confirmed" or "tracking number assigned" and transitioning the order to the next logical state.

  • Idea 3 (A "Subscription" Management Model): A user's subscription in a SaaS application could be a state machine. It could be in a Trial state, an Active state, a PastDue state, or a Canceled state. If a user in the Active state misses a payment, they transition to PastDue. If they then pay, they return to Active. This cleanly separates the logic for each stage of the customer lifecycle.

🐰 The Rabbit Hole

  • Dive Deeper: The "Refactoring.Guru" website has another excellent explanation, this time for the State pattern. It uses the example of a document's behavior in a publishing workflow to clearly illustrate how the context delegates actions to different state objects.

Our mission is to unearth the world's most powerful, overlooked ideas. If you know of a technology that is trapped in a niche, overshadowed by hype, or simply deserves a bigger spotlight, please submit it for a future issue here.

Till next time,

Sleeping Giants

Keep reading

© 2026 Sleeping Giants.
Report abusePrivacy policyTerms of use
beehiivPowered by beehiiv