在……的領域中物件導向分析與設計，管理使用者動作與系統狀態需要穩健的架構方法。命令模式作為一種基本的結構解決方案，特別是在處理可撤銷的操作時尤為重要。此設計模式將請求封裝為物件，使您能以不同請求參數化客戶端、排隊請求或記錄操作。本指南探討如何使用此模式實作撤銷功能，而無需依賴特定的軟體工具。
理解核心目標 🎯
此架構模式的主要目標是將發起操作的物件與執行操作的物件分離。在建構需要可撤銷的操作的應用程式時，複雜度會顯著增加。使用者期望能撤銷錯誤。開發人員必須確保系統狀態在撤銷後仍保持一致。命令模式透過將動作視為一等物件來解決此問題。
想像一個使用者修改文件的情境。若發生錯誤，系統必須回復到先前狀態。這不僅僅是一次函式呼叫，而是一個請求物件。透過將「儲存」、「刪除」或「修改」的邏輯封裝成命令，系統便獲得彈性。如此一來，便能堆疊這些命令、檢視操作歷史，並個別撤銷。
- 封裝： 執行動作所需的所有資訊都包含在命令物件中。
- 解耦： 呼叫者無需知道接收者的細節。
- 可擴充性： 可在不修改現有客戶端程式碼的情況下新增命令。
命令架構的關鍵元件 ⚙️
要有效實作可撤銷的操作，必須理解四個主要角色。每個角色都有其特定責任，共同維持系統的穩定性。
1. 客戶端 🧑💻
客戶端建立命令物件。它知道應將哪個接收者與哪個命令關聯，以及命令所需的參數。在典型的作業流程中，客戶端初始化具體命令，設定必要的狀態，並將其傳遞給呼叫者。
2. 命令介面 📜
這是抽象合約。它宣告了一個執行方法。任何實作此介面的命令類別都必須提供執行動作的邏輯。為了支援撤銷功能，具體命令還需實作反向方法。這種分離使系統能區分「執行」與「撤銷」。
3. 接收者 🖥️
接收者包含實際的商業邏輯。它知道如何執行操作。例如，在文字編輯情境中，接收者管理文字緩衝區。命令物件會呼叫接收者的的方法，但不需知道接收者實作細節。
4. 呼叫者 🚀
呼叫者負責觸發命令。它儲存對命令物件的參考，並呼叫其執行方法。關鍵的是，針對可撤銷的操作，呼叫者通常會管理一個歷史堆疊。它不知道命令的具體作用；它只知道如何執行該命令。
| 組件 | 責任 | 範例情境 |
|---|---|---|
| 客戶端 | 實例化命令 | 使用者點擊按鈕 |
| 命令介面 | 定義 execute/undo 方法 | 抽象基類 |
| 接收者 | 執行實際工作 | 文字緩衝區管理員 |
| 呼叫者 | 管理歷史記錄與執行 | 應用程式主迴圈 |
實作歷史堆疊 📚
的關鍵在於可撤銷的操作命令歷史的管理。當使用者執行一個動作時，系統必須記錄該動作。當請求撤銷時，系統必須取得最近的動作，將其反轉，然後從活躍的歷史記錄中移除。
堆疊機制
堆疊資料結構是此目的的理想選擇。它遵循後進先出（LIFO）原則。最近執行的命令會是第一個被撤銷的。這與使用者的預期完全一致。
- 推入： 當命令成功執行時，它會被推入堆疊。
- 弹出： 當觸發撤銷時，堆疊頂端的命令會被彈出。
- 查看： 系統可以在不移除的情況下檢視頂端命令，這對於UI指示器非常有用。
處理多層級
實作單一層撤銷相當簡單。實作多個多級取消需要仔細的狀態管理。呼叫者必須維持一個命令物件的持久列表。當使用者執行操作時，該列表會增長；當使用者取消時，列表會縮小。
考慮以下工作流程：
- 使用者執行動作 A。命令 A 被執行。命令 A 被加入歷史記錄。
- 使用者執行動作 B。命令 B 被執行。命令 B 被加入歷史記錄。
- 使用者取消。命令 B 被彈出。呼叫命令 B.reverse()。
- 使用者再次取消。命令 A 被彈出。呼叫命令 A.reverse()。
此結構確保系統狀態能完全回復到動作序列開始前的狀態。
設計反向邏輯 🔄
要使一個命令真正可取消，它必須具備一種機制來反轉其效果。這通常是設計中最複雜的部分。並非所有操作都能以簡單的方式反向執行。
狀態保留
某些命令需要在執行前保存狀態。如果命令修改了一個複雜物件，則必須保留原始狀態，以便在取消階段恢復。這通常由命令物件本身處理，保存執行前接收者狀態的快照。
方法簽名設計
命令介面應明確定義一個取消方法。這可確保所有命令類型之間的合約一致性。
execute()：執行正向操作。undo()：反轉操作。
透過強制執行此介面，呼叫者會以統一的方式處理所有命令。它不需要知道命令是「儲存」還是「刪除」。它只需對堆疊頂端的任何命令呼叫undo()即可。
擴展至重做功能 🔄
雖然取消功能至關重要，重做重做則能提供完整的使用者體驗。重做允許使用者重新執行先前已取消的命令。這需要第二個堆疊或分離的歷史管理策略。
重做堆疊
當發生取消時，命令物件不會被銷毀。相反地，它會從取消堆疊移動到重做堆疊。如果使用者選擇重做，命令會從重做堆疊中彈出並重新執行。
分支邏輯
當在撤銷後執行新操作時，會出現一個問題。重做歷史記錄將變得無效。如果使用者撤銷了三個步驟，然後輸入一個新字元，先前的「重做」步驟將無法再達成。在此情況下，必須清除重做堆疊。
- 情境： 使用者編輯文字 ➔ 撤銷變更 ➔ 輸入新文字。
- 結果： 之前的撤銷步驟將遺失。
- 實作： 在執行新命令時，清除重做堆疊。
實作中的挑戰 ⚠️
雖然命令模式為可撤銷操作提供了清晰的結構，但仍然存在若干挑戰。開發人員必須解決這些問題，以確保系統的效能與穩定性。
記憶體消耗
歷史堆疊中儲存的每個命令物件都會消耗記憶體。在長時間運行且操作頻繁的會話中，這可能導致顯著的記憶體使用量。每個命令可能需要儲存對接收者狀態的參考。
- 解決方案：限制允許的撤銷層級數量。
- 解決方案：在可能的情況下使用弱參考。
- 解決方案：針對類似動作實作命令壓縮。
並發問題
如果應用程式處理多個執行緒，歷史堆疊必須是執行緒安全的。使用者可能在另一個執行緒執行不同命令時撤銷一個動作。競爭條件可能導致狀態損壞。
- 同步：在推入和彈出操作期間鎖定歷史堆疊。
- 排隊：使用執行緒安全的佇列來管理命令執行順序。
複雜的反向邏輯
並非所有動作都有簡單的反向操作。刪除檔案很容易撤銷（恢復檔案）。更新資料庫記錄則較困難（需要交易日誌）。命令物件必須封裝足夠的資訊，以反向執行特定動作。
設計的最佳實務 📝
為了維持清晰的架構，在實作命令模式以支援可撤銷操作.
- 保持命令簡潔： 每個命令應代表單一邏輯操作。除非操作是原子性的，否則避免將無關的操作批量合併到一個命令中。
- 記錄狀態變更： 清楚定義在
execute()中發生的狀態變更，以及undo()恢復的內容。這有助於未來的維護。 - 記錄錯誤： 如果命令在執行過程中失敗，就不應被加入歷史堆疊中。使用者不應能撤銷一個失敗的操作。
- 介面分離： 如果命令無法撤銷，就不應強制其實現 undo 方法。應為可執行與可撤銷命令使用不同的介面。
與其他模式的比較 🔍
雖然命令模式非常適合用於 可撤銷的操作，但它經常與備忘錄模式進行比較。理解兩者的差異有助於選擇合適的工具。
| 功能 | 命令模式 | 備忘錄模式 |
|---|---|---|
| 重點 | 動作封裝 | 狀態封裝 |
| 撤銷機制 | 反轉邏輯 | 恢復先前狀態 |
| 效能 | 若邏輯簡單，記憶體使用較低 | 狀態快照需要較高記憶體 |
| 複雜度 | 需要反向邏輯 | 需要快照邏輯 |
當操作較為複雜且反向邏輯明確時，建議使用命令模式。當狀態過於複雜而無法邏輯上逆轉時（例如保存整個視窗的狀態），則備忘錄模式更為合適。
現實世界應用場景 🌍
此模式不僅限於文字編輯器，還適用於各種需要狀態管理的領域。
金融系統
在銀行軟體中，交易必須可逆。若發現錯誤，提款命令可被撤銷。命令模式確保帳本始終保持一致。
圖形設計工具
繪製形狀時，使用者期望能移動、調整大小和刪除物件。每次工具互動都轉化為一個命令。歷史堆疊可支援複雜的編輯會話，且不會造成資料遺失。
設定管理
系統管理員經常變更設定。若變更導致系統故障，能夠回復到先前設定至關重要。命令封裝了設定變更。
結構上的最後想法 🏗️
實作可撤銷的操作使用命令模式實作可撤銷操作需要仔細規劃。這將重點從直接函數呼叫轉移到物件導向的封裝。呼叫者負責管理流程，而命令物件則負責管理邏輯。
透過遵循關注點分離的原則，開發者能建立穩健且使用者友善的系統。歷史堆疊成為使用者體驗的骨幹，提供安全與彈性。雖然記憶體與並行處理方面存在挑戰，但透過適當的架構決策，這些問題皆可管理。
此方法確保軟體持續可維護。新增功能不會破壞現有的撤銷邏輯。解耦使得系統能持續演進，而無需不斷重構核心執行引擎。