Refactoring Task

Overview

This exercise addresses a structure where the management of inquiry ticket states is handled by a single method using conditional branches.
You are to identify the design issues from the perspectives of extensibility, maintainability, and testability, and propose a viable refactoring plan.

Initial Code

The following implementation defines a handle() method that transitions a support ticket through the following states: open → in_progress → resolved → closed.
All state-dependent behaviors and transitions are hardcoded using if statements within the same method, making it difficult to accommodate future changes or new states.

TypeScript

class SupportTicket {
  private status: string = "open"; // 状態: open, in_progress, resolved, closed

  handle() {
    if (this.status === "open") {
      console.log("チケットを処理中に設定します");
      this.status = "in_progress";
    } else if (this.status === "in_progress") {
      console.log("チケットを解決済みに設定します");
      this.status = "resolved";
    } else if (this.status === "resolved") {
      console.log("チケットをクローズします");
      this.status = "closed";
    } else if (this.status === "closed") {
      console.log("このチケットはすでに終了しています");
    }
  }
}

PHP

<?php

class SupportTicket {
  private string $status = "open"; // 状態: open, in_progress, resolved, closed

  public function handle(): void {
    if ($this->status === "open") {
      echo "チケットを処理中に設定します\n";
      $this->status = "in_progress";
    } elseif ($this->status === "in_progress") {
      echo "チケットを解決済みに設定します\n";
      $this->status = "resolved";
    } elseif ($this->status === "resolved") {
      echo "チケットをクローズします\n";
      $this->status = "closed";
    } elseif ($this->status === "closed") {
      echo "このチケットはすでに終了しています\n";
    }
  }
}

Python

class SupportTicket:
    def __init__(self):
        self.status = "open"  # 状態: open, in_progress, resolved, closed

    def handle(self):
        if self.status == "open":
            print("チケットを処理中に設定します")
            self.status = "in_progress"
        elif self.status == "in_progress":
            print("チケットを解決済みに設定します")
            self.status = "resolved"
        elif self.status == "resolved":
            print("チケットをクローズします")
            self.status = "closed"
        elif self.status == "closed":
            print("このチケットはすでに終了しています")

Question 1: What design problems exist in this code?

List and explain specific issues based on the following perspectives:

• All state-specific logic is centralized in a single method
• Difficult to add new states or transition conditions
• Violates SRP (Single Responsibility Principle) and OCP (Open/Closed Principle)
• Hard to test or reuse individual transitions

Question 2: How can this structure be made more maintainable and flexible?

Formulate an improvement plan based on the following points:

• How can logic for each state be separated and encapsulated?
• What would the class design look like if each state were modeled as its own object?
• What design patterns would be effective, and why?

Example: Design Pattern Candidates

Pattern Name	Purpose and Effects
State	Encapsulates state-specific behavior in separate classes and handles transitions
Strategy	Provides flexible selection of behavior (when transition control is external)
Command	Treats each operation as an object, enabling tracking of state changes and undo
Observer	Notifies external components when state changes, enabling reactive state updates

Optional Extensions

• If new states such as "on_hold" or "escalated" are introduced, how would the structure accommodate them?
• If state transitions depend on user permissions or action types, how would you incorporate such conditions into the design?

Suggested Output Format (for review or study groups)

• List of at least three structural problems
• Refactoring strategy and rationale behind chosen patterns
• Design sketch or textual flow of the improved structure (e.g., class relationships or method delegation)