在軟體架構的版圖中，很少有概念能像狀態與行為之間的關係那樣基礎。這兩個支柱構成了物件導向分析與設計（OOAD）的骨幹。當開發人員建構系統時，他們本質上是在定義儲存資訊並執行動作的實體。掌握這些元素如何互動，對於建構可維護、可擴展且健壯的應用程式至關重要。本指南探討物件結構的細微之處，不依賴特定廠商工具，而是聚焦於適用於各種程式設計範型的通用原則。
物件導向分析的基礎 🧱
物件導向分析與設計（OOAD）將焦點從程序邏輯轉向以資料為中心的建模。OOAD 不將程式視為一系列步驟，而是將其視為一組互動的物件集合。每個物件代表問題領域中的一個獨特實體。要有效建模這些實體，必須理解物件的雙重本質：它知道什麼，以及它能做什麼。
狀態指的是物件在特定時間點的狀況。它儲存在變數中，通常稱為屬性或性質。行為指的是物件可以執行的動作。這些以方法或函式實現。這兩個概念的區分與互動決定了軟體架構的品質。
定義軟體系統中的狀態 📦
狀態是物件內部持續存在的資料。它代表實體的歷史、目前設定或身分。若無狀態，物件將成為一組靜態的邏輯集合，無法適應不同的輸入或情境。在實務上，狀態是透過記憶體配置來管理的。
- 屬性：這些是用來儲存資料的具名容器。例如，使用者物件可能包含姓名、電子郵件地址和狀態旗標。
- 資料類型：狀態可以是基本類型（數字、布林值）或複雜類型（指向其他物件的參考）。
- 可見性：對狀態的存取通常受到限制，以確保資料完整性。公開狀態允許從任何地方進行修改，而私有狀態則將存取限制在內部方法中。
狀態的生命週期至關重要。物件被實例化後，其狀態被初始化，接著透過行為經歷修改，最終被銷毀。在其存在期間，狀態可能會改變多次。管理這些變化是設計中的主要考量。
狀態的類型
並非所有狀態都同等重要。區分不同類型的狀態有助於管理複雜度。
- 實例狀態：每個從類別建立的物件獨有。兩個使用者物件即使類型相同，其名稱也可能不同。
- 類別狀態：在所有實例之間共享。已建立的使用者總數計數器可能儲存在此處。
- 暫存狀態：不需要持久化的資料。例如，使用後即被遺棄的暫時計算結果。
- 持久狀態：存活於應用程式生命週期之外的資料，通常儲存在資料庫或檔案系統中。
定義軟體系統中的行為 ⚙️
行為是物件的動態面向。它定義了物件如何回應訊息或方法呼叫。行為是修改或存取狀態的機制。若無行為，狀態將是靜態且無活力的。
方法封裝了邏輯。它們可根據其目的分類：
- 存取子：檢索關於狀態的資訊，但不進行修改。
- 變異子：變更物件的狀態。
- 轉換器：執行可能變更狀態或回傳新資料的複雜操作。
- 查詢：根據目前狀態回傳布林值或狀態檢查結果。
行為應具內聚性。單一方法理想上應執行一項明確的任務。若一個方法試圖更新資料庫、計算稅率並發送電子郵件，則很可能承擔了過多職責。行為的高內聚性使程式碼更易於測試與理解。
封裝與資料隱藏 🔒
狀態與行為之間的橋樑是封裝。此原則將資料與操作該資料的方法捆綁成單一單位。更重要的是，它限制對物件某些組件的直接存取。這稱為資料隱藏。
透過隱藏內部狀態，物件可保護自身免受無效修改。若屬性為公開，程式的任何部分均可將其設為無效值；若為私有，則僅該物件自身的方法可修改它。這使物件得以強制執行不變式。
封裝的好處
- 保護：防止外部對關鍵資料的干擾。
- 彈性：內部實作可變更而不影響外部程式碼。
- 簡潔性：物件的使用者與簡潔的介面互動，而非複雜的資料結構。
以銀行帳戶為例：餘額是狀態，存款與提領方法是行為。若餘額為公開，使用者可直接將其設為負數，繞過業務規則。將餘額設為私有，僅允許透過提領方法進行修改，系統即可確保餘額在未獲授權的情況下不會低於特定門檻。
狀態與行為比較 📊
為釐清差異，下表概述物件情境中狀態與行為的關鍵區別。
| 特性 | 狀態 | 行為 |
|---|---|---|
| 定義 | 物件所持有的資料。 | 物件所執行的動作。 |
| 儲存 | 記憶體變數（欄位/屬性）。 | 可執行程式碼（方法/函式）。 |
| 可見性 | 通常為私有，以保護完整性。 | 通常為公開，以允許互動。 |
| 變更 | 在物件的生命週期中會發生變更。 | 除非重構，否則保持不變。 |
| 範例 | 價格、數量、狀態。 | 計算總額、更新狀態、儲存。 |
模擬現實世界實體 🏗️
有效的物件導向分析與設計（OOAD）依賴於將現實世界的概念映射到程式碼。此過程需要識別每個實體相關的狀態與行為。讓我們以一個通用的「車輛」為例。
車輛物件分析
- 狀態：
- 目前速度
- 顏色
- 引擎狀態（運行中/已停止）
- 燃油量
- 行為：
- 加速
- 煞車
- 加油
- 關閉
請注意，行為取決於狀態。「加速」方法在「引擎狀態為「已停止」時無法運作。此外，此動作會改變狀態。呼叫「加速」會增加「目前速度.
此依賴關係建立了一個契約。行為定義了狀態轉換的規則。設計良好的物件可確保這些轉換合乎邏輯且安全。
管理狀態轉換 🔄
在複雜系統中，物件經常會經歷不同的狀態。這通常使用有限狀態機來建模。一個物件可能處於 待處理狀態，然後轉換到 啟用，最後轉換到 已完成.
並非所有轉換都是有效的。您無法直接從 已完成轉換到 待處理。行為必須強制執行這些規則。如果嘗試執行違反狀態機的操作，系統應以優雅的方式處理，例如拋出錯誤或忽略該請求。
- 有效轉換：確保資料一致性。
- 無效轉換：觸發錯誤處理或警告。
- 副作用：某些轉換會觸發其他物件中的事件（例如，當訂單出貨時發送通知）。
常見設計陷阱 ⚠️
即使是經驗豐富的架構師，在管理狀態與行為時也可能會失誤。識別這些模式有助於避免技術債。
1. 上帝物件
上帝物件是一個知道太多且執行太多工作的實體。它匯集了系統的所有狀態與行為。這使得該物件難以測試、維護與重現。解決方案是將該物件分解為更小、更專注的單元。
2. 狀態洩漏
當內部狀態未經適當封裝而暴露給外部世界時，就會發生此問題。例如，傳回內部清單的參考，允許外部程式碼直接修改該清單，繞過物件的邏輯。這會破壞物件的完整性。
3. 緊耦合
當一個物件的行為過度依賴另一個物件的內部狀態時，這些物件就會緊耦合。修改其中一個物件可能會破壞另一個物件。目標是實現鬆耦合，讓物件透過明確定義的介面互動，而非共用記憶體。
4. 到處都是可變狀態
過度可變性會使程式碼難以推論。若物件的狀態隨時可能改變，除錯將變得困難。請考慮在可能的情況下使用不可變狀態，或將可變性限制在特定方法中。
測試與驗證 🧪
測試狀態與行為需要雙重方法。單元測試應驗證行為是否產生預期的狀態變更；整合測試則應驗證物件之間是否正確互動。
- 狀態測試：斷言方法呼叫後，物件的屬性具有正確的數值。
- 行為測試：斷言方法執行時無錯誤，並執行預期的邏輯。
- 互動測試：斷言物件向其他物件傳送正確的訊息。
模擬物件常用於模擬相依物件的狀態。這能隔離被測試的行為，確保受檢視的邏輯是唯一的變數。
永續架構的最佳實踐 ✅
為確保軟體設計的長遠性與清晰度，請遵循以下關於狀態與行為的原則。
- 單一職責：物件應只有一個變更理由。若狀態管理與業務邏輯的演進速率不同，請將兩者分離。
- 明確命名：屬性名稱應描述狀態（例如：”
isCompleted“).方法名稱應描述動作（例如：”complete). - 最小化暴露：僅暴露必要的最少狀態。在可能的情況下使用唯讀屬性。
- 驗證：在進入點驗證狀態。切勿假設外部程式碼會提供有效資料。
- 不可變性：當狀態無需變更時，請優先使用不可變物件。這能簡化並行處理與推論。
- 依賴注入：請注入相依物件，而非在內部建立。這允許在不變更狀態邏輯的情況下替換行為。
遵循這些指引，開發者能建立更易擴充的系統。新增功能可透過引入新物件或擴充現有行為來實現，而不會破壞核心狀態管理的穩定性。
物件「持有什麼」與「執行什麼」之間的區別不僅是技術細節，更是一種解決問題的哲學方法。當狀態與行為正確對應時，程式碼便能準確反映領域模型。這種對應關係降低了任何閱讀或維護系統者的認知負荷，並將一組指令轉化為軟體所支援的現實世界流程的具體呈現。
維持這種平衡需要持續的關注。隨著需求演變，狀態可能需要擴展，或行為可能需要調整。物件的結構必須能容納這些變更，而無需進行全面重寫。這種韌性正是良好物件導向分析與設計的標誌。