Implementing the State Pattern in C# for Finite State Machines

Walk into any Sydney software shop, from a fintech in the CBD to a logistics startup in Surry Hills, and you will find engineers wrestling with the same tangled problem: an object that behaves differently depending on where it is in its lifecycle. Order processing, document approval, payment reconciliation, IoT device orchestration, claim handling at an insurer — they all share a hidden shape. That shape has a name, and it has been hiding in plain sight inside the GOF playbook since 1994.

A finite state machine is a mathematical idea dressed in software clothing. It models a system that can exist in exactly one state at a time, transitions between states based on events or conditions, and never wanders outside a defined set of possibilities. Picture an e-commerce order moving from Pending to Paid to Shipped to Delivered, or a traffic light cycling through Red, Amber, and Green. These are not metaphors; they are the same formal model your compiler uses to parse code and your microwave uses to time popcorn.

C# developers often reach for enums and switch statements first because the syntax is familiar and the compiler does not complain. That approach works for two or three states, occasionally four. Then a product owner in Melbourne asks for a refund flow, a Brisbane compliance officer requires an audit trail on every transition, and suddenly the switch statement grows tentacles. Conditional logic sprawls across the codebase, every change risks breaking an unrelated case, and unit tests balloon to cover every combination of states and events.

The State pattern offers a way out. By promoting each state to a class that implements a shared interface, you let polymorphism carry the burden of branching. Transitions become first-class objects. Logic that lived inside one bloated method is distributed across small, testable units. The result reads more like a story of what an object does at each step rather than a flowchart of nested ifs, and it slots neatly into modern C# features such as records, pattern matching, and async event handlers.

What a finite state machine really looks like in code

A minimal machine has four ingredients: a set of states, a set of events, a transition function that maps (state, event) to a new state, and an initial state. In C# terms, that translates to an enum or sealed class hierarchy for states, a method on the context for each event, and a small table of rules. The vocabulary is deliberately dry because the underlying idea is rigorous; it has been used in hardware design, protocol stacks, and game AI for decades.

Consider a concrete example drawn from the Australian fintech world. A buy-now-pay-later provider operating under an Australian Financial Services Licence must track each customer account through states such as Active, Overdue, Hardship, and WrittenOff. APRA's CPS 234 standard demands that material information security incidents be reported promptly, and the Notifiable Data Breaches scheme under the Privacy Act 1988 adds another layer of accountability. A state machine is the natural model because compliance officers want to know exactly which transitions are legal and which events trigger an obligation.

Another everyday example sits inside the team chat apps used by distributed squads across Adelaide and Perth. A pull request moves from Draft to Review to Approved to Merged and, sometimes, to Reverted. Each transition carries side effects: notifications to reviewers, CI pipeline triggers, audit log entries. Encoding those flows as a state machine prevents the kind of bug where a reviewer is pinged for a request that was already merged hours ago, and it gives on-call engineers a single source of truth when something looks wrong at three in the morning AEST.

Why the State pattern beats a switch statement

Switch statements look innocent. They are also one of the most common sources of subtle regressions in long-lived C# codebases. When you add a new state, you must remember every place that switches on the enum, and the compiler will not warn you about the ones you missed. A type hierarchy, by contrast, forces the decision: extend the base class or interface, override the methods you care about, and let the runtime dispatch the right behaviour.

The pattern also plays well with dependency injection. Each state class can receive the services it needs through constructor injection, which is a common pattern in ASP.NET Core applications running on Australian government platforms and cloud-certified infrastructure. If a state needs to call out to a payment gateway or send a message through Azure Service Bus, the wiring happens once at composition time, not scattered through conditional blocks.

Performance is rarely a concern. The dispatch overhead of a virtual call in modern .NET on a 64-bit Linux VM in an AWS Sydney region is measured in nanoseconds. Readability, however, scales poorly with switch statements. A new engineer joining your Brisbane team can read a state class and immediately see its responsibilities, whereas a 400-line switch statement demands a flowchart and a strong coffee before anyone can refactor with confidence.

Designing the context and the state interface

Start by defining a contract that every state must honour. In a typical order-processing example, that interface might expose HandlePayment, HandleShipment, HandleCancellation, and a read-only Current property. Keep the surface small; states should be cohesive, not god objects. If you find yourself passing five parameters into a state method, that is a signal the abstraction is wrong and the state should be doing less or the context should hold more.

The context class holds the current state and forwards calls to it. It also exposes an internal transition mechanism — usually a private setter or an internal method on the state interface — so only states can change the context's state. This is the same encapsulation principle you would apply to any object that owns mutable lifecycle data. A common idiom in modern C# is to expose the current state as a read-only property and let state classes call back into the context through a protected method or an internal interface, which keeps the public API honest.

Names matter. Call the property Status rather than Mode or Thing, because domain experts from Perth to Parramatta use the word status when they describe the lifecycle of an order, a claim, or an account. Borrow vocabulary from the business, not from computer science textbooks. When the code reads like the business, the next refactor is cheaper and the conversation with stakeholders becomes shorter.

Wiring up concrete states and transitions

Each concrete state class implements the interface and contains the logic that applies when the object is in that state. The PendingState of an order, for instance, knows how to handle a payment but throws or no-ops on a shipment event. The PaidState knows how to handle shipment but rejects further payment events. The behaviour is encoded in the type system rather than scattered across conditional checks.

Transitions are typically expressed in one of two ways. The first is explicit: each state method either returns a new state or calls a transition method on the context with the next state as a parameter. The second is delegated: states raise events that the context consumes, and a transition table maps events to destinations. The first approach is easier to read; the second is easier to configure at runtime. Pick based on whether your state graph is fixed at compile time or changes per tenant, which is a real concern for SaaS products serving customers in Sydney, Melbourne, and regional Queensland alike.

Teams that pair state machines with infrastructure automation keep their dev, test, and prod environments in lockstep with the application's behavioural model. A good primer on ARM templates and Bicep shows how this works in practice, particularly when you validate a state machine against multiple data sources during a release.

Side effects, guards, and persistence

Rarely does a transition happen in isolation. Sending a confirmation email, writing to an audit table, publishing a domain event to a message bus — these are the side effects that give a state machine its business value. The cleanest approach is to separate the decision (which state comes next) from the consequences (what happens as a result). Many C# teams use the mediator pattern, with handlers dispatched after the transition completes, to keep state classes focused on decision-making and side effects free of branching.

Guards are conditions that must hold before a transition fires. A guard might check that the customer's address is valid before moving an order from Paid to Shipped, or that an employee has the right role before approving a refund over A$1,000. Guards belong either in the state class or in a dedicated validator, depending on how much logic they carry. Resist the urge to scatter guard checks throughout the transition logic; centralise them so auditing is straightforward when the regulator asks for proof.

Persistence deserves its own thought. If your state machine lives inside a SQL Server database hosted in an Australian Azure region, the database row should record the current state, the timestamp of the last transition, and ideally a history table of every transition for compliance purposes. This is not paranoia; it is what auditors expect when they review systems that handle financial data under the Privacy Act and APRA prudential standards. Treating the state as a column with CHECK constraints gives you referential integrity, while a separate transition log gives you the audit trail.

Testing, refactoring, and common pitfalls

Testing a state machine is satisfying once the structure is right. Each state class can be unit-tested in isolation by providing a mock context and verifying that the right transition method is invoked. Transition tables can be tested as data: given a state and an event, assert the destination. Integration tests then walk a full lifecycle from initial to terminal states, which catches guards that depend on real services such as payment gateways or shipping APIs.

Refactoring an existing switch-based machine into the State pattern is usually mechanical. Identify each case branch, lift it into a class, replace the enum dependency with an interface, and inject the initial state. Tools like Roslyn analyzers can flag switch statements over enums that might benefit from refactoring, and a few teams in Australia's .NET community have published editorconfig snippets to enforce the convention across large codebases.

A common pitfall is over-engineering. A two-state boolean does not need the State pattern, and a five-state machine with no transitions beyond the obvious might be clearer as a switch. The pattern pays off when the state graph has branches, cycles, or external side effects, and when the domain experts themselves speak in terms of states and events. Another pitfall is allowing states to know about each other explicitly; they should communicate through the context, not directly. Finally, resist the temptation to merge the State pattern with the Strategy pattern unless you genuinely have behaviour that varies independently of state; the two patterns look similar but solve different problems.