# State Pattern

The State Pattern is a behavioral design pattern that lets an object alter its behavior when its internal state changes. It appears as if the object changed its class.

## 1. The Core Concept

The pattern is closely related to the concept of a **Finite State Machine**.
*   **Context:** The main object (e.g., a `Document`). It holds a reference to the current state object.
*   **State Interface:** Defines methods for all state-specific behaviors.
*   **Concrete States:** Implement behaviors specific to a state (e.g., `Draft`, `Moderation`, `Published`).

Instead of a massive `switch` statement inside the Context (`switch (state) { case 'DRAFT': ... }`), the Context delegates the work to the current State object.

## 2. Analogy: Smartphone Buttons

Consider the power button on your phone:
*   **If Screen is Off:** Pressing it turns the screen On.
*   **If Screen is On:** Pressing it turns the screen Off.
*   **If Phone is Locked:** Pressing it might show the lock screen.

The button is the same, but the behavior changes based on the phone's state.

## 3. Example (TypeScript)

Let's model a simple Document workflow.

```typescript
// The State Interface
interface State {
    publish(): void;
}

// The Context
class Document {
    private state: State;

    constructor() {
        this.state = new DraftState(this);
    }

    changeState(state: State) {
        this.state = state;
    }

    publish() {
        this.state.publish();
    }
}

// Concrete State 1: Draft
class DraftState implements State {
    private document: Document;

    constructor(document: Document) {
        this.document = document;
    }

    publish() {
        console.log("Draft published. Moving to Moderation.");
        this.document.changeState(new ModerationState(this.document));
    }
}

// Concrete State 2: Moderation
class ModerationState implements State {
    private document: Document;

    constructor(document: Document) {
        this.document = document;
    }

    publish() {
        console.log("Moderation passed. Document is now Live.");
        this.document.changeState(new PublishedState(this.document));
    }
}

// Concrete State 3: Published
class PublishedState implements State {
    private document: Document;

    constructor(document: Document) {
        this.document = document;
    }

    publish() {
        console.log("Document is already published.");
    }
}

// Usage
const doc = new Document();
doc.publish(); // Output: Draft published. Moving to Moderation.
doc.publish(); // Output: Moderation passed. Document is now Live.
doc.publish(); // Output: Document is already published.
```

## 4. State vs. Strategy

They look very similar (both use composition to delegate behavior), but the intent differs.
*   **Strategy:** The Client usually chooses the strategy (e.g., "Use PayPal"). Strategies are often independent and unaware of each other.
*   **State:** The State objects often know about each other and initiate transitions (e.g., Draft moves itself to Moderation). The state transitions are part of the logic.

## 5. Pros and Cons

| Pros | Cons |
| :--- | :--- |
| **SRP:** Organizes code related to specific states into separate classes. | **Complexity:** Overkill if the state machine has only a few states or rarely changes. |
| **Open/Closed:** Add new states without changing existing state classes or the context. | **Coupling:** State classes often depend on the Context (to trigger transitions). |
| **Simplification:** Removes massive conditional logic (`if/else` or `switch`) from the context. | |

## 6. Finite State Machines (FSM)

A Finite State Machine (FSM) is a mathematical model of computation. It is an abstract machine that can be in exactly one of a finite number of states at any given time.

### Components
*   **States:** A finite set of conditions (e.g., `Idle`, `Running`, `Paused`).
*   **Transitions:** Rules that dictate how the machine moves from one state to another (e.g., `Idle` -> `Running`).
*   **Events (Inputs):** Triggers that cause transitions (e.g., `Press Start Button`).

### Relation to State Pattern
The State Pattern is essentially an object-oriented implementation of a Finite State Machine.
*   Each **State** in the FSM becomes a concrete class.
*   **Transitions** are logic inside these classes that switch the Context to a new State class.

[[programming/design-patterns]]
[[programming/object-oriented-programming]]
[[programming/strategy-pattern]]