Single State Handling

Description

What does it look like?

• Object behavior varies by internal state, but state and behavior are tightly coupled
• State-specific behavior is managed using if or switch statements
• As states increase, the logic bloats and becomes harder to read

Why is it a problem?

• Each new state requires modifying existing code (violates the Open/Closed Principle)
• Responsibilities are concentrated in a single class, leading to low readability and difficult testing
• Future expansions and state transition logic become complex and error-prone

Bad Example of the Anti-pattern

TypeScript

class Document {
  private state: string = "draft"; // 状態: 'draft', 'review', 'published'

  publish() {
    if (this.state === "draft") {
      console.log("レビュー依頼を送信");
      this.state = "review";
    } else if (this.state === "review") {
      console.log("公開しました");
      this.state = "published";
    } else if (this.state === "published") {
      console.log("すでに公開済みです");
    }
  }
}

PHP

<?php

class Document {
  private string $state = "draft"; // 状態: 'draft', 'review', 'published'

  public function publish(): void {
    if ($this->state === "draft") {
      echo "レビュー依頼を送信\n";
      $this->state = "review";
    } elseif ($this->state === "review") {
      echo "公開しました\n";
      $this->state = "published";
    } elseif ($this->state === "published") {
      echo "すでに公開済みです\n";
    }
  }
}

Python

class Document:
    def __init__(self):
        self.state = "draft"  # 状態: 'draft', 'review', 'published'

    def publish(self):
        if self.state == "draft":
            print("レビュー依頼を送信")
            self.state = "review"
        elif self.state == "review":
            print("公開しました")
            self.state = "published"
        elif self.state == "published":
            print("すでに公開済みです")

Issues:

• State is managed as a plain string, and behavior is centralized in a single method
• Whenever a new state is added, publish() must be modified
• Mixing state and logic in one place makes the design fragile and hard to extend

Refactoring by Pattern

Design patterns that can address this

Pattern	Overview	Main Refactoring Approach
State	Separate objects by state and delegate behavior	Manage state explicitly using classes
Strategy	Replace behavior externally	Let external context control state switching
Command	Encapsulate state-specific actions as command objects	Represent behavior as objects for flexibility