設計模式深度解析：State 模式的適用場景與實作策略

State 模式定義

State 模式核心思想：不同狀態，不同行為，即每個狀態擁有相應的行為邏輯。

何時使用 State 模式？

核心適用場景：狀態切換

當系統頻繁出現 if-else if-else 進行狀態判斷切換時，應考慮 State 模式。不僅限於狀態，物件屬性不同導致行為差異（如資料庫記錄的 property 欄位標識特殊性質）同樣適用。

「開關切換狀態」vs「一般狀態判斷」

一般狀態判斷： 狀態值由外部變數決定，狀態間無關聯

if (which == 1) state = "hello";
else if (which == 2) state = "hi";
else if (which == 3) state = "bye";

開關切換狀態（State 模式適用）： 狀態按固定或可變規則相互轉換，如旋轉開關

if (state.equals("bye")) state = "hello";
else if (state.equals("hello")) state = "hi";
else if (state.equals("hi")) state = "bye";

進一步判斷標準

• 單向固定循環（hello→hi→bye→hello）不一定需要 State，否則會過度設計
• 若出現反向切換、任意切換、或多動作觸發不同切換路徑（如 push/pull 兩種操作對應不同轉換邏輯），則強烈建議使用 State

實戰案例分析

顏色切換案例

public class Context {
    private Color state = null;

    public void push() {
        if (state == Color.red) state = Color.blue;
        else if (state == Color.blue) state = Color.green;
        else if (state == Color.black) state = Color.red;
        else if (state == Color.green) state = Color.black;
        new Sample(state).operate();
    }

    public void pull() {
        // 反向切換邏輯
        if (state == Color.green) state = Color.blue;
        else if (state == Color.black) state = Color.green;
        else if (state == Color.blue) state = Color.red;
        else if (state == Color.red) state = Color.black;
        new Sample2(state).operate();
    }
}

此例中 push/pull 兩種動作導致狀態雙向切換，適合 State 模式優化。但若狀態行為極簡單（單純賦值），引入 State 反而增加子類複雜度，需權衡。

經典適用案例

• 銀行帳戶： Open/Close 狀態頻繁轉換
• TCP 連線： Created/Listening/Closed 三狀態循環，行為邏輯複雜
• POP3 郵箱： Start/HaveUsername/Authorized/Quit 四狀態，各狀態行為龐大
• 繪圖工具選擇： 矩形/直線/曲線工具切換，屬於狀態切換

State 模式結構

需兩類實體參與：

1. State Manager（狀態管理器/開關）： 如上例 Context，負責狀態切換動作
2. State 介面及具體狀態類： 封裝各狀態專屬行為

實作建議

• 將狀態切換邏輯從 Manager 移至具體狀態類內部（如 state.handlePush(context)）
• Context 持有當前狀態引用，委派行為給狀態物件
• 狀態轉換由具體狀態類決定下一狀態，降低耦合
• 避免為簡單賦值邏輯濫用模式，導致類別爆炸