Understanding the State Pattern: Managing Complex Object Behaviors

An e-commerce order workflow typically travels through multiple states including draft, pending, paid, shipped, delivered, cancelled, and refunded. Every single operation relies directly on the current state: payments are allowed exclusively when pending, shipments only when paid, and cancellations only if not yet shipped. Consequently, source code often degrades into repetitive cascades of conditional checks like if ($this->status === 'pending') across all methods.

This design creates architectural bottlenecks. The cancel() method must inspect whether the current state permits cancellation, ship() verifies shipping authorization, and refund() evaluates refund eligibility. Introducing any new state or operation forces developers to update every single method and inspection point simultaneously. Complexity scales multiplicatively as states multiply by operations; managing 7 states alongside 6 operations yields 42 distinct conditions that must be continuously synchronized.

"permette a un oggetto di alterare il proprio comportamento quando il suo stato interno cambia. L'oggetto sembrera cambiare la propria classe"

Gang of Four

To address this, the Gang of Four defined the State Pattern as a behavioral design pattern that "allows an object to alter its behavior when its internal state changes. The object will appear to change its class." The architecture outlines specific structural actors, starting with an OrderStateInterface containing methods such as pay, ship, cancel, refund, and getStatus.

Stock photo for illustration only, not from the actual event

When a novel state arrives—such as OnHoldState for orders paused during anti-fraud checks—developers simply implement a new class matching OrderStateInterface. This class explicitly defines permitted operations and valid transitions while leaving all other states completely untouched. No methods inside the Order class require modification, satisfying the Open/Closed Principle naturally.