State and Chain of Responsibility Patterns

# CHAPTER 16

State and Chain of Responsibility Patterns #

1. Introduction #

2. Learning Objectives #

• Define the intent and mechanics of the State Pattern.

• Eliminate "Finite State Machine" switch statements using polymorphism.

• Define the intent of the Chain of Responsibility (CoR) Pattern.

• Architect a decoupled, sequential request-processing pipeline.

• Identify the differences between State management and Chain routing.

3. The State Pattern (The Finite State Machine) #

• The Problem: A Document object can be in Draft, Review, or Published state. If a user clicks "Publish", the logic depends entirely on the current state. If you handle this with a giant switch ($this->state) block inside every single method, the code rots.

• The Solution: Extract each state into its own class (DraftState, PublishedState). The Document (Context) holds a reference to one of these state objects. When the user clicks "Publish", the Document simply delegates the action to its current State object.

4. The Chain of Responsibility (The Pipeline) #

• The Problem: A user submits a form. You need to 1) Authenticate the session, 2) Validate the data, 3) Check for spam. If you hardcode these 3 checks sequentially in the controller, they become tightly coupled.

• The Solution: Create 3 independent "Handler" objects. Link them together like a linked list (Auth points to Validation points to Spam). You hand the request to the first Handler. If it passes Auth, the Auth handler hands it to Validation. If a handler fails, it instantly rejects the request, breaking the chain.

5. State vs. Strategy #

• Strategy: The Context relies on the client to give it a Strategy (e.g., The user clicks "Bike Route"). Strategies *do not know* about each other.

• State: The States actively transition *themselves* (e.g., The DraftState finishes review and automatically swaps the Context over to the PublishedState). States *know* about each other.

6. UML Diagrams #

[ Client ] ---> [ Handler Interface ]
                    + handleRequest()
                    + setNext(Handler)
                           ^
                           | (Implements)
                ---------------------------
                |                         |
        [ ConcreteHandler A ] ---> [ ConcreteHandler B ]

7. Code Example: Chain of Responsibility (PHP) #

<?php
// --- 1. The Handler Interface ---
abstract class Middleware {
    private $nextHandler;

    public function linkWith(Middleware $next): Middleware {
        $this->nextHandler = $next;
        return $next; // Return next to allow method chaining
    }

    public function check($request): bool {
        // If there is no next handler, we made it to the end successfully
        if (!$this->nextHandler) {
            return true;
        }
        // Pass the request to the next link in the chain
        return $this->nextHandler->check($request);
    }
}

// --- 2. Concrete Handlers (The Checks) ---
class ThrottlingMiddleware extends Middleware {
    private $requestsPerMinute = 0;

    public function check($request): bool {
        if ($this->requestsPerMinute >= 5) {
            echo "Request Failed: Rate limit exceeded!\n";
            return false; // BREAK THE CHAIN
        }
        $this->requestsPerMinute++;
        echo "Throttling passed...\n";
        return parent::check($request); // Continue to next handler
    }
}

class AuthenticationMiddleware extends Middleware {
    public function check($request): bool {
        if ($request[&#039;token'] !== 'secret_123') {
            echo "Request Failed: Invalid Auth Token!\n";
            return false; // BREAK THE CHAIN
        }
        echo "Authentication passed...\n";
        return parent::check($request); // Continue
    }
}

class RoleMiddleware extends Middleware {
    public function check($request): bool {
        if ($request[&#039;role'] !== 'admin') {
            echo "Request Failed: User is not an Admin!\n";
            return false; // BREAK THE CHAIN
        }
        echo "Role check passed. Access Granted!\n";
        return parent::check($request); // Continue
    }
}

// --- 3. Client Code (Building the Chain) ---
$middleware = new ThrottlingMiddleware();
$middleware->linkWith(new AuthenticationMiddleware())
           ->linkWith(new RoleMiddleware()); // Linked List established!

// --- 4. Execution ---
echo "--- Request 1 (Hacker) ---\n";
$middleware->check([&#039;token' => 'bad_token', 'role' => 'user']);
// Output: 
// Throttling passed...
// Request Failed: Invalid Auth Token! (Chain broken)

echo "\n--- Request 2 (Admin) ---\n";
$middleware->check([&#039;token' => 'secret_123', 'role' => 'admin']);
// Output: 
// Throttling passed...
// Authentication passed...
// Role check passed. Access Granted!
?>

8. Best Practices #

• The "Catch-All" Fallback: In a Chain of Responsibility, what happens if a request reaches the very end of the chain and *no* handler processed it? Depending on the architecture, it might silently disappear. Always ensure your chain has a default "Catch-All" handler at the very end to log unhandled requests or throw an explicit Exception.

9. Common Mistakes #

• State Pattern Overhead: A junior developer implements the State pattern for an Order object, creating 15 different State classes. *The Failure:* If an Order state only determines a string value in the database and doesn't drastically change the *behavior* of the methods, the State pattern is massive overkill. A simple enum or string field is sufficient. Only use the State pattern when the *logic* of the object's methods completely changes based on its status.

10. Mini Project: Build an Order Workflow (State) #

1. 1. Context: Create an Order class.

1. 2. State Interface: Create a State interface with pay(), ship(), and cancel().

1. 3. States: Create PendingState, PaidState, ShippedState.

1. 4. Logic: In PendingState, pay() works and transitions the context to PaidState. In ShippedState, calling cancel() throws an error ("Cannot cancel shipped order").

1. 5. Action: Test the workflow. Notice how the Order class has no if/else statements.

11. Practice Exercises #

1. 1. Explain how the Chain of Responsibility pattern is heavily utilized in modern web frameworks (like Laravel or Express.js) under the term "Middleware."

1. 2. Define the architectural difference between the Strategy pattern and the State pattern regarding how they transition between their internal objects.

12. MCQs with Answers #

13. Interview Questions #

• Q: In a Chain of Responsibility, walk me through the memory implications of creating a very long linked list of Handlers. Can this pattern cause Stack Overflow exceptions if poorly implemented?

• Q: Explain how the State pattern resolves the architectural "Code Smell" of a massive Finite State Machine switch block. How does it leverage polymorphism?

• Q: Compare the Chain of Responsibility pattern with the Decorator pattern. Structurally, they both involve objects containing references to other objects of the same type. How do their behavioral intents differ?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #