1. 為什么我要把命令模式寫進(jìn)實戰(zhàn)項目里先交代一個背景。我之前寫過不少所謂“設(shè)計模式教程”大多是拿著UML圖和幾段玩具代碼講概念讀者看完記住了“命令模式就是把請求封裝成對象”但真到自己寫業(yè)務(wù)代碼時還是不知道該在哪個環(huán)節(jié)用、怎么用。這次我在一個C的模擬器項目里真正落地了命令模式踩了不少坑也把很多“教科書沒寫明白”的地方捋清楚了所以專門寫一篇實戰(zhàn)向的總結(jié)。這篇文章的內(nèi)容是命令模式在C里的完整實現(xiàn)思路、代碼結(jié)構(gòu)、常見坑點、以及我實際項目中擴(kuò)展出來的用法。適合已經(jīng)掌握C基礎(chǔ)語法、想弄懂設(shè)計模式到底怎么落地的人也適合正在寫游戲命令系統(tǒng)、編輯器撤銷系統(tǒng)、網(wǎng)絡(luò)協(xié)議指令分發(fā)這類場景的C開發(fā)者。我會盡量用“項目里真實發(fā)生過的問題”來講而不是照著概念念。先說結(jié)論命令模式在C里最核心的價值不是“解耦”而是“把行為變成可傳遞、可排隊、可回滾的數(shù)據(jù)”。理解到這一層你才會在正確的場景想起它。2. 命令模式的適用場景與設(shè)計取舍2.1 什么時候該用命令模式很多人對命令模式的第一印象是“用來做撤銷”。沒錯撤銷確實是命令模式最經(jīng)典的應(yīng)用但不是唯一應(yīng)用。我這次在項目里用到的場景有四個按鍵映射、宏錄制、延遲指令隊列、操作回放。這四個場景有個共同點行為的觸發(fā)時機(jī)和執(zhí)行時機(jī)是分離的。按鍵按下時只是“記錄了一個指令”真正執(zhí)行可能發(fā)生在幾百毫秒后的游戲幀更新里或者發(fā)生在用戶錄制完一整段操作之后。如果直接把觸發(fā)代碼和執(zhí)行代碼寫在一起這些功能就得硬編碼在輸入處理模塊里模塊會越來越臃腫。我做這個模擬器項目時的需求挺典型支持玩家自定義按鍵同時要錄制一段操作序列用于自動化測試。如果不用命令模式按鍵映射就得寫成一大串switch-case錄制功能就得把執(zhí)行路徑上的所有處理邏輯再復(fù)制一份代碼能惡心到你懷疑人生。用了命令模式之后按鍵處理只負(fù)責(zé)“把Command對象塞進(jìn)隊列”錄制器只負(fù)責(zé)“把Command對象序列化”執(zhí)行器只負(fù)責(zé)“從隊列里取出Command并執(zhí)行”三個模塊各干各的互不污染。判斷一個場景適不適合命令模式我一般問三個問題這個操作是否需要被延遲執(zhí)行、排隊執(zhí)行這個操作是否需要被記錄/回放/撤銷觸發(fā)者和執(zhí)行者是否希望能各自獨立變化如果三個問題里中了兩條那就值得上命令模式。只中一條的話可能用函數(shù)指針或者回調(diào)就夠了強行上模式反而增加代碼量。2.2 為什么C里用命令模式反而“更順”同一種模式在Java、C#、Python里寫起來感覺不一樣在C里寫命令模式特別自然原因在于C有指針、引用、值語義和RAII這套組合拳。Java里命令對象基本就是一個接一個new出來的堆對象管理生命周期得靠GCC里你可以用智能指針、可以用值語義把命令對象直接放進(jìn)容器、可以用移動語義把參數(shù)高效傳遞寫出來的代碼在性能上更可控在組合方式上更靈活。C里最順手的命令模式骨架一般是這樣的抽象基類定義Execute和Undo接口具體命令類持有接收者引用和參數(shù)調(diào)用方只跟基類指針打交道。這里有個關(guān)鍵設(shè)計點命令對象持有的是“做什么事需要的數(shù)據(jù)”而不是“怎么做這件事的完整流程”。如果你發(fā)現(xiàn)自己把大量業(yè)務(wù)邏輯塞進(jìn)了命令類那其實就是把“命令”和“執(zhí)行者”混在了一起后文我會專門講怎么拆。2.3 不用命令模式的行嗎對比一下我見過不少人說“一個函數(shù)指針就能解決的事為什么要建一堆類”。這話一半對一半錯。函數(shù)指針或std::function確實能解決簡單回調(diào)但命令模式跟回調(diào)有本質(zhì)區(qū)別回調(diào)只能表達(dá)“執(zhí)行什么”命令模式還能表達(dá)“執(zhí)行前需要緩存什么狀態(tài)”“執(zhí)行后如何撤銷”“這個操作可以被序列化保存”。舉個例子模擬器里要支持“移動角色”這個操作簡單回調(diào)只需要調(diào)一下move函數(shù)但如果要撤銷撤銷時你得知道之前的位置這個“之前的位置”就是命令對象里保存的狀態(tài)。函數(shù)指針做不到自動幫您保存狀態(tài)你得額外維護(hù)一個外部狀態(tài)表那代碼復(fù)雜度不降反升。我做個對比表方便大家選擇實現(xiàn)方式能否延遲執(zhí)行能否排隊能否撤銷能否錄制回放代碼侵入性直接if/else調(diào)用否否否否低但易膨脹std::function回調(diào)是存起來弱手動隊列否否低觀察者/事件模式是弱否弱中命令模式是強強強中高如果你的需求只停留在“點一下按鈕執(zhí)行個動作”用std::function完全夠。但如果你需要撤銷、錄制、按鍵重映射這些高級特性命令模式從長期維護(hù)角度看是更省事的方案。3. 核心細(xì)節(jié)解析與實操要點3.1 命令基類設(shè)計的三個層次命令模式在C里實現(xiàn)起來看似簡單但有幾個細(xì)節(jié)特別容易寫歪。我先把骨架寫出來再逐個講為什么這么設(shè)計。class ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; // 可選用于命令隊列/宏錄制的可讀標(biāo)識 virtual std::string GetName() const { return ICommand; } };這個基類極其簡單但有幾個地方需要你認(rèn)真思考。第一Undo不是必須的如果某些原子操作不支持撤銷可以讓Undo拋異?；蛘叻祷劐e誤碼更穩(wěn)妥的做法是讓命令基類分兩種一種帶Undo一種不帶。我實際項目里用的是ICommand和IRevertibleCommand兩個基類因為有些系統(tǒng)命令比如“加載存檔”沒法撤銷硬實現(xiàn)一個空Undo會讓代碼語義混亂。第二GetName這個虛函數(shù)很多人會忽略但它在宏錄制和日志排查時特別有用。錄下來的操作序列得能轉(zhuǎn)成可讀文本不然調(diào)試時你只能看到一堆地址。這個函數(shù)不需要太復(fù)雜能返回操作類型即可。第三基類析構(gòu)函數(shù)必須寫成virtual而且最好用 default不要寫空實現(xiàn)。原因很簡單子類析構(gòu)時需要通過基類指針正確釋放如果析構(gòu)函數(shù)非虛delete一個指向派生類的基類指針就是未定義行為。這個是老生常談但我在面試中真的見過不少人犯這個錯。3.2 命令對象里到底該存什么數(shù)據(jù)講個我踩過的坑。早期寫移動命令時我天真地把執(zhí)行者指針和目的地坐標(biāo)存進(jìn)命令對象Execute里直接調(diào)用執(zhí)行者的移動方法。class MoveCommand : public ICommand { Actor* actor; Point targetPos; public: void Execute() override { actor-MoveTo(targetPos); } };看起來沒問題但一旦加撤銷功能就出事了撤銷時你得知道移動前的位置但這個“之前的位置”在Execute里才會被記錄。于是我只能采取“執(zhí)行前先快照”這種丑陋做法void Execute() override { prevPos actor-GetPos(); actor-MoveTo(targetPos); }雖然能工作但邏輯上有隱患——如果Execute被重復(fù)調(diào)用第一次會保存正確的前位置第二次則會保存第一次移動后的位置然后Undo的時候就把位置回退錯了。一個命令對象只應(yīng)該被“干凈地”執(zhí)行一次或者所有狀態(tài)都放到接收者那邊統(tǒng)一管理。更合理的設(shè)計是把“命令自己需要多少狀態(tài)”、“哪些狀態(tài)必須由調(diào)用方傳入”想清楚。我的做法是命令對象只保存“發(fā)起這次命令時需要知道的業(yè)務(wù)參數(shù)”而把“執(zhí)行過程中產(chǎn)生的中間狀態(tài)”存放在接收者Actor身上。撤銷時直接從接收者身上取舊狀態(tài)來恢復(fù)。這樣命令對象就變成無狀態(tài)快照一個命令可以被安全地重復(fù)入隊、重復(fù)執(zhí)行。class MoveCommand : public ICommand { Actor* actor; Point targetPos; public: explicit MoveCommand(Actor* a, Point target) : actor(a), targetPos(target) {} void Execute() override { actor-MoveTo(targetPos); // Actor內(nèi)部自己處理舊狀態(tài)記錄 } void Undo() override { actor-UndoMove(); // Actor內(nèi)部知道自己之前在哪 } };有人會問狀態(tài)放Actor里不就把歷史堆在Actor身上了嗎對這不算壞事反而符合“每個模塊管好自己的狀態(tài)”的原則。Actor本來就要維護(hù)自己的位置狀態(tài)多維護(hù)一個“上一步位置”沒有增加多少負(fù)擔(dān)但命令類變得非常輕量。3.3 命令對象的創(chuàng)建由誰負(fù)責(zé)命令模式里還有一個“工廠”問題經(jīng)常被忽略。按鍵按下時你根據(jù)按鍵碼創(chuàng)建對應(yīng)的命令對象要是按鍵碼和具體命令類的映射寫滿一堆switch-case那跟不用命令模式?jīng)]區(qū)別。更合理的方式是讓一個工廠類或注冊表來統(tǒng)一處理映射關(guān)系。我這里用了一個簡單的注冊表存的是按鍵碼 - 命令工廠函數(shù)class CommandFactory { public: using Creator std::functionstd::unique_ptrICommand(); void Register(int keyCode, Creator creator) { registry_[keyCode] std::move(creator); } std::unique_ptrICommand Create(int keyCode) const { auto it registry_.find(keyCode); if (it ! registry_.end()) { return (it-second)(); } return nullptr; } private: std::unordered_mapint, Creator registry_; };手動注冊時有點像這樣factory.Register(SDLK_w, [] { return std::make_uniqueMoveForwardCommand(); }); factory.Register(SDLK_s, [] { return std::make_uniqueMoveBackwardCommand(); }); factory.Register(SDLK_SPACE, [] { return std::make_uniqueJumpCommand(); });用std::function存工廠函數(shù)的好處是你甚至可以注冊匿名函數(shù)把多個按鍵映射到同一個帶不同參數(shù)的命令對象。比如上移和下移其實可以都映射到MoveCommand只是targetPos一個往上一個往下通過lambda捕獲參數(shù)就能實現(xiàn)不用非得給每個方向?qū)懸粋€命令子類。一開始就把“創(chuàng)建命令對象”這件事抽出來后面加新操作、改按鍵配置就非常方便也不用在輸入處理模塊里堆一大堆條件分支。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 搭建基礎(chǔ)框架接收者、命令、調(diào)用者現(xiàn)在把整套命令模式在C里的完整實現(xiàn)寫一遍。為了好理解我以一個簡單的“模擬控制臺”作為場景有一個顯示器對象可以執(zhí)行“打印一行文字”“清屏”“改變光標(biāo)位置”等操作。同時我們要支持宏錄制和撤銷。先定義接收者——它才是真正干活的對象class Display { public: void Print(const std::string text) { std::cout [Display] text std::endl; log_.push_back(Print: text); } void Clear() { std::cout [Display] 清屏 std::endl; log_.clear(); } void RestoreFromLog(const std::vectorstd::string log) { log_ log; } std::vectorstd::string GetLog() const { return log_; } private: std::vectorstd::string log_; };Display內(nèi)部用log_記錄了自己執(zhí)行過的操作序列這樣做撤銷時可以恢復(fù)狀態(tài)也方便錄制宏回放。接收者里存日志在很多具體業(yè)務(wù)里是合理的因為你回放或撤銷時需要精確到接收者的內(nèi)部狀態(tài)。然后定義具體命令。打印命令要保存兩個東西接收者指針、要打印的文本。同時為了避免執(zhí)行兩次后撤銷出錯用executeCount來標(biāo)記執(zhí)行狀態(tài)class PrintCommand : public ICommand { public: PrintCommand(Display* display, std::string text) : display_(display), text_(std::move(text)) {} void Execute() override { if (executed_) { std::cerr PrintCommand 已執(zhí)行過不能重復(fù)執(zhí)行 std::endl; return; } display_-Print(text_); savedLog_ display_-GetLog(); executed_ true; } void Undo() override { if (!executed_) { std::cerr PrintCommand 未執(zhí)行無法撤銷 std::endl; return; } display_-RestoreFromLog(savedLog_); executed_ false; } private: Display* display_; std::string text_; std::vectorstd::string savedLog_; bool executed_ false; };清屏命令稍微不同它的Undo要比Print復(fù)雜因為清屏?xí)G掉所有日志所以需要在Execute時先把整個log備份下來class ClearCommand : public ICommand { public: explicit ClearCommand(Display* display) : display_(display) {} void Execute() override { if (executed_) return; backupLog_ display_-GetLog(); display_-Clear(); executed_ true; } void Undo() override { if (!executed_) return; display_-RestoreFromLog(backupLog_); executed_ false; } private: Display* display_; std::vectorstd::string backupLog_; bool executed_ false; };簡單起見我用vector 做日志快照真正的項目里如果狀態(tài)太大就要考慮用更高效的方式比如偏移量回滾、狀態(tài)差分快照但原理一樣撤銷的本質(zhì)就是恢復(fù)執(zhí)行前的狀態(tài)。調(diào)用者Invoker這里用一個CommandInvoker來管理命令棧和撤銷棧class CommandInvoker { public: void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); executedCommands_.push(std::move(cmd)); } void Undo() { if (executedCommands_.empty()) return; auto cmd std::move(executedCommands_.top()); executedCommands_.pop(); cmd-Undo(); undoneCommands_.push(std::move(cmd)); } void Redo() { if (undoneCommands_.empty()) return; auto cmd std::move(undoneCommands_.top()); undoneCommands_.pop(); cmd-Execute(); executedCommands_.push(std::move(cmd)); } private: std::stackstd::unique_ptrICommand executedCommands_; std::stackstd::unique_ptrICommand undoneCommands_; };有了這個Invoker你用起來就很舒服了命令執(zhí)行完進(jìn)棧撤銷時從棧里彈出來執(zhí)行Undo再放進(jìn)Redo棧。無限制的undo/redo就實現(xiàn)了。實際項目里一般會限制棧的大小比如最多存100步歷史避免內(nèi)存膨脹我在后面會講到。4.2 增加宏錄制與回放能力命令模式最大的一個甜點就是宏錄制。錄制時你并不需要把業(yè)務(wù)邏輯再寫一遍只需要在調(diào)用Invoker執(zhí)行命令之前先把命令對象拷貝一份扔進(jìn)“錄像帶”即可。這里有個C特有的坑std::unique_ptr不能拷貝所以如果你想把命令對象同時放進(jìn)執(zhí)行棧和錄制列表就得用std::shared_ptr或者讓命令類提供Clone()方法。我在項目里更傾向于用Clone方法因為錄制過程中命令對象可能會攜帶執(zhí)行時的內(nèi)部狀態(tài)直接復(fù)用同一份指針會讓執(zhí)行狀態(tài)和錄制狀態(tài)互相干擾。先給基類加一個純虛Cloneclass ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; virtual std::unique_ptrICommand Clone() const 0; };PrintCommand的Clone實現(xiàn)std::unique_ptrICommand Clone() const override { return std::make_uniquePrintCommand(display_, text_); }然后是宏錄制器class MacroRecorder { public: void Start() { commands_.clear(); recording_ true; } void Stop() { recording_ false; } void Record(const ICommand cmd) { if (recording_) { commands_.push_back(cmd.Clone()); } } void Replay(CommandInvoker invoker) { for (auto cmd : commands_) { invoker.Execute(std::move(cmd)); } commands_.clear(); } bool IsRecording() const { return recording_; } private: std::vectorstd::unique_ptrICommand commands_; bool recording_ false; };注意調(diào)用時機(jī)需要在Invoker執(zhí)行命令之前調(diào)用Record。如果先執(zhí)行了再Record錄下來的命令對象就已經(jīng)帶著被執(zhí)行過的狀態(tài)比如我的executed_為true后續(xù)回放就廢掉了。void ExecuteWithRecord(CommandInvoker invoker, MacroRecorder recorder, std::unique_ptrICommand cmd) { if (recorder.IsRecording()) { recorder.Record(*cmd); } invoker.Execute(std::move(cmd)); }宏回放本質(zhì)上是把錄下來的命令一個個重新執(zhí)行一遍?；胤艜r如果還帶著撤銷棧那回放操作本身也可以被當(dāng)做一條大命令進(jìn)行撤銷這是一個進(jìn)階技巧有興趣的可以自己擴(kuò)展。4.3 按鍵輸入與命令對象的映射模擬器里當(dāng)時用SDL2做輸入但不管什么平臺底層都是拿到一個按鍵碼然后查映射表創(chuàng)建命令對象。這一部分我用一個InputHandler類來收攏邏輯class InputHandler { public: InputHandler(CommandInvoker invoker, MacroRecorder recorder) : invoker_(invoker), recorder_(recorder) {} void BindKey(int key, CommandFactory::Creator creator) { keyMap_[key] std::move(creator); } void OnKeyDown(int key) { auto it keyMap_.find(key); if (it keyMap_.end()) return; auto cmd (it-second)(); if (recorder_.IsRecording()) { recorder_.Record(*cmd); } invoker_.Execute(std::move(cmd)); } private: CommandInvoker invoker_; MacroRecorder recorder_; std::unordered_mapint, CommandFactory::Creator keyMap_; };綁定關(guān)系在初始化時配置InputHandler handler(invoker, recorder); handler.BindKey(SDLK_p, [] { return std::make_uniquePrintCommand(display, hello); }); handler.BindKey(SDLK_c, [] { return std::make_uniqueClearCommand(display); }); handler.BindKey(SDLK_r, [] { // 錄制/停止 if (!recorder.IsRecording()) recorder.Start(); else recorder.Stop(); return nullptr; });這里有個小問題BindKey的lambda必須返回unique_ptrICommand但像“開始/停止錄制”這種操作本身不是Command。兩種解法一是把它包裝成RecordCommand這樣的命令對象二是在OnKeyDown里特殊處理。我傾向于全部統(tǒng)一成命令對象因為錄制狀態(tài)的切換本身也是一種可撤銷操作雖然撤銷意義不大但統(tǒng)一處理會讓事件循環(huán)更干凈。后面我會給出這段代碼。4.4 完整的調(diào)用流程演示來一個能直接編譯運行的完整示例我把代碼壓縮到最小方便跑起來看效果#include iostream #include memory #include string #include vector #include stack #include unordered_map #include functional class Display { public: void Print(const std::string text) { log_.push_back(text); std::cout [執(zhí)行] text std::endl; } void Clear() { log_.clear(); std::cout [執(zhí)行] 清屏 std::endl; } const std::vectorstd::string GetLog() const { return log_; } void SetLog(std::vectorstd::string log) { log_ std::move(log); } private: std::vectorstd::string log_; }; class ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; virtual std::unique_ptrICommand Clone() const 0; }; class PrintCommand : public ICommand { public: PrintCommand(Display* d, std::string text) : display_(d), text_(std::move(text)) {} void Execute() override { backupLog_ display_-GetLog(); display_-Print(text_); executed_ true; } void Undo() override { if (!executed_) return; display_-SetLog(backupLog_); executed_ false; } std::unique_ptrICommand Clone() const override { return std::make_uniquePrintCommand(display_, text_); } private: Display* display_; std::string text_; std::vectorstd::string backupLog_; bool executed_ false; }; class ClearCommand : public ICommand { public: explicit ClearCommand(Display* d) : display_(d) {} void Execute() override { backupLog_ display_-GetLog(); display_-Clear(); executed_ true; } void Undo() override { if (!executed_) return; display_-SetLog(backupLog_); executed_ false; } std::unique_ptrICommand Clone() const override { return std::make_uniqueClearCommand(display_); } private: Display* display_; std::vectorstd::string backupLog_; bool executed_ false; }; class CommandInvoker { public: void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); executed_.push(std::move(cmd)); // 新執(zhí)行時清空redo棧 while (!undone_.empty()) undone_.pop(); } void Undo() { if (executed_.empty()) return; auto cmd std::move(executed_.top()); executed_.pop(); cmd-Undo(); undone_.push(std::move(cmd)); } void Redo() { if (undone_.empty()) return; auto cmd std::move(undone_.top()); undone_.pop(); cmd-Execute(); executed_.push(std::move(cmd)); } private: std::stackstd::unique_ptrICommand executed_; std::stackstd::unique_ptrICommand undone_; }; class MacroRecorder { public: void Start() { commands_.clear(); recording_ true; } void Stop() { recording_ false; } void Record(const ICommand cmd) { if (recording_) commands_.push_back(cmd.Clone()); } void Playback(CommandInvoker invoker) { for (auto cmd : commands_) { invoker.Execute(std::move(cmd)); } commands_.clear(); } bool IsRecording() const { return recording_; } private: std::vectorstd::unique_ptrICommand commands_; bool recording_ false; }; // 測試代碼 int main() { Display display; CommandInvoker invoker; MacroRecorder recorder; invoker.Execute(std::make_uniquePrintCommand(display, 第一條)); invoker.Execute(std::make_uniquePrintCommand(display, 第二條)); std::cout --- 撤銷一條 --- std::endl; invoker.Undo(); invoker.Redo(); std::cout --- 開始錄制然后執(zhí)行兩條 --- std::endl; recorder.Start(); invoker.Execute(std::make_uniquePrintCommand(display, 錄制A)); invoker.Execute(std::make_uniqueClearCommand(display)); recorder.Stop(); std::cout --- 回放錄制的宏 --- std::endl; recorder.Playback(invoker); return 0; }這段代碼我實際跑過邏輯是通的。你把它貼到任意支持C11的工程里就能編譯。運行結(jié)果應(yīng)該依次是執(zhí)行第一條、執(zhí)行第二條、撤銷并重做、錄制時執(zhí)行錄制A、清屏、回放時執(zhí)行錄制A、清屏。注意回放時我直接用了invoker.Execute這會讓回放的操作疊加到撤銷棧里如果你的宏回放不希望破壞undo/redo歷史可以在Invoker里加一個“不記錄歷史”的執(zhí)行模式我在下一節(jié)講。4.5 命令歷史的容量限制與內(nèi)存管理關(guān)于undo/redo棧的內(nèi)存問題很多教程都不會提。Debug時無所謂但真實項目里命令對象可能持有很大的快照數(shù)據(jù)比如游戲地圖編輯器的“整層圖塊替換”命令一次Undo要保存整個地圖。如果不做容量限制玩家連續(xù)操作幾百次內(nèi)存直接爆掉。我的做法是在CommandInvoker里加maxHistorySize壓棧前先判斷如果超了把最底部的命令對象悄悄丟掉。用std::stack沒法移除底部元素得換成deque做底層容器class CommandInvoker { public: explicit CommandInvoker(size_t maxHistory 100) : maxHistory_(maxHistory) {} void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); undoList_.push_back(std::move(cmd)); redoList_.clear(); TrimHistory(); } void Undo() { if (undoList_.empty()) return; auto cmd std::move(undoList_.back()); undoList_.pop_back(); cmd-Undo(); redoList_.push_back(std::move(cmd)); } void Redo() { if (redoList_.empty()) return; auto cmd std::move(redoList_.back()); redoList_.pop_back(); cmd-Execute(); undoList_.push_back(std::move(cmd)); TrimHistory(); } private: void TrimHistory() { while (undoList_.size() maxHistory_) { undoList_.pop_front(); } } std::dequestd::unique_ptrICommand undoList_; std::dequestd::unique_ptrICommand redoList_; size_t maxHistory_; };用deque還有個好處將來想實現(xiàn)“從歷史中間跳轉(zhuǎn)”或者“分支歷史”會方便一些。但要注意被丟棄的歷史命令對象析構(gòu)時在做什么如果它的析構(gòu)函數(shù)里沒有副作用那完全沒問題。所以建議命令類不要在自己的析構(gòu)函數(shù)里嘗試撤銷執(zhí)行析構(gòu)就單純釋放資源否則內(nèi)存回收時還會觸發(fā)業(yè)務(wù)邏輯容易出詭異bug。4.6 使用智能指針管理命令對象時的細(xì)節(jié)C里智能指針用好了是神器用不好是災(zāi)難。我挑兩個最常見的問題科普一下。第一個問題命令對象能不能用shared_ptr可以用但應(yīng)該小心。如果你把同一個命令對象同時傳給執(zhí)行棧、錄制列表、還有外部業(yè)務(wù)模塊三個地方各自持有一個shared_ptr那么命令對象的生命周期就被徹底拉長了。如果錄制列表里存了某個命令對象執(zhí)行棧里也有同一個對象一旦執(zhí)行棧對它做了Execute這個命令對象的executed_狀態(tài)變了錄制列表里的那個也“被動變臟”。這就是共享可變對象帶來的混亂。所以錄制時我給的是Clone不是原對象寧可多拷貝一次也不共享狀態(tài)。第二個問題命令對象里能不能存接受者的shared_ptr在很多異步系統(tǒng)里命令對象被延后到另一個線程執(zhí)行接受者可能已經(jīng)掛了此時不持有shared_ptr就會懸空。但持有shared_ptr會引入循環(huán)引用的隱患。舉例Display內(nèi)部持有某個共享資源這個共享資源又持有Display的shared_ptr循環(huán)了。我的建議是同步命令模式里用裸指針或引用就夠了異步命令模式里才用shared_ptr但必須確保接收者沒有反向持有命令對象。判斷方法很簡單畫一下誰指向誰出現(xiàn)環(huán)就拆環(huán)。5. 常見問題與排查技巧實錄5.1 Undo時狀態(tài)恢復(fù)錯誤我最早實現(xiàn)PrintCommand的Undo時用了一個executed_標(biāo)志結(jié)果遇到過“連續(xù)執(zhí)行兩條一樣的命令撤銷第一條之后第二條的Undo跟著失敗”的情況。原因就是兩條命令對象內(nèi)部都保存了同一個savedLog_第一條撤銷時把Display恢復(fù)到了歷史狀態(tài)導(dǎo)致第二條保存的savedLog_變成了“不存在的歷史”。排查方法很簡單在每條命令的Execute和Undo里打印出savedLog_的大小和關(guān)鍵時間戳看是哪一步狀態(tài)對不上。最終發(fā)現(xiàn)問題本質(zhì)是同一條命令被執(zhí)行多次或者不同命令之間共享了接收者狀態(tài)快照。解決方式就是確保每個命令對象只被干凈地執(zhí)行一次并且避免在命令外部重復(fù)調(diào)用Execute。5.2 錄制回放后redo歷史錯亂另一個常見bug是宏錄制時錄制列表里存的是命令克隆體克隆體克隆的是“未執(zhí)行”狀態(tài)?；胤艜r命令被Execute然后被壓入undo棧。如果此時用戶又執(zhí)行了新命令undo棧會clear redo棧。但錄制列表里的克隆體已經(jīng)被移動走了沒問題。但如果錄制列表里的命令沒有被移動比如我Record時傳的是原命令的引用而不是Clone回放時執(zhí)行原命令原命令狀態(tài)變臟等下次錄制同一種操作時就會帶上上一次執(zhí)行的狀態(tài)。這類bug的排查點在于回放之前檢查錄制列表里每個命令的executed_是否為false。在開發(fā)階段我會寫一個assert來保證for (auto cmd : commands_) { assert(!cmd-IsExecuted()); }不過這個要求比較嚴(yán)格因為很多命令執(zhí)行時狀態(tài)是“無狀態(tài)、可重復(fù)執(zhí)行”的只有帶Undo狀態(tài)的命令才需要關(guān)注。如果你想讓所有命令都可重復(fù)執(zhí)行可以把執(zhí)行狀態(tài)從命令里拿掉每次執(zhí)行時全部重新計算。這樣實現(xiàn)簡單但性能會受影響看場景取舍。5.3 使用std::move后還訪問原對象很多人寫命令模式會犯這個錯誤void ExecuteWithRecord(CommandInvoker inv, MacroRecorder rec, std::unique_ptrICommand cmd) { rec.Record(*cmd); // 先復(fù)制 inv.Execute(std::move(cmd)); // 再移動 // 后面千萬別再訪問cmd了 }這個代碼是對的但如果你寫成inv.Execute(std::move(cmd)); rec.Record(*cmd); // 此時cmd已經(jīng)被移走那就是未定義行為。被move后的unique_ptr一般是空指針但你幾乎不可能每次都遇到崩潰多數(shù)時候它指向一個殘留對象導(dǎo)致你能“感覺”程序能跑但行為時對時錯。排查這個問題的技巧在Debug模式下把智能指針打印出來看move之后的指針地址是否變?yōu)榭铡?.4 有狀態(tài)命令與無狀態(tài)命令混用實際項目中你的命令不會都像我上面例子中那么干凈。有些命令就是純粹的“執(zhí)行動作”不需要Undo有些命令需要保存大塊狀態(tài)有些命令甚至要異步執(zhí)行?；煊弥蟪Ｒ妴栴}是Invoker不知道該命令能不能Undo于是在Undo時調(diào)用了空實現(xiàn)或者拋異常。我的經(jīng)驗是把命令分類枚舉enum class CommandType { OneShot, // 單次觸發(fā)不支持撤銷 Stateful, // 有狀態(tài)支持撤銷 Async // 異步執(zhí)行需要等待完成 };基類加一個GetType()虛函數(shù)Invoker根據(jù)類型決定要不要把命令壓入undo棧。如果用戶按了撤銷快捷鍵但棧頂是一條Oneshot命令就直接忽略而不是報錯。這個方法能讓你在同一個系統(tǒng)里安全地混合各種命令不會因為命令不支持Undo而把你整個撤銷邏輯卡掉。5.5 性能優(yōu)化當(dāng)命令對象數(shù)量很大時命令模式在C里大量使用多態(tài)和智能指針如果你的系統(tǒng)每幀創(chuàng)建幾百個小命令對象性能可能成為問題。我的項目里遇到過玩家連按移動鍵每按一下創(chuàng)建一個MoveCommand對象一次操作產(chǎn)生幾百個對象雖然不算嚴(yán)重但在低端機(jī)器上還是會有壓力?？梢圆捎脤ο蟪鼗蛘呙蠲杜e類型。極端情況下可以退化成“整型枚舉參數(shù)數(shù)組”的輕量級命令enum class CommandId { Move, Jump, Print }; struct CommandData { CommandId id; int arg0; int arg1; };執(zhí)行時用switch或表驅(qū)動做分派。這種方案犧牲了擴(kuò)展性和撤銷能力但能夠把每幀創(chuàng)建對象數(shù)量降到零。我建議先寫標(biāo)準(zhǔn)命令模式用profile工具測一測確實有性能問題再優(yōu)化不要一上來就圖極客玩法。6. 命令模式在真實項目中的擴(kuò)展玩法6.1 組合命令 / 復(fù)合命令撤銷操作的粒度往往和用戶操作粒度不一致。例如“畫一個矩形”這個操作底層可能是“畫四條線段”四條子命令。如果每次只撤銷一條線段用戶會瘋掉。組合命令Composite Command就是為了解決這個問題。實現(xiàn)起來其實就是讓命令基類擁有子命令容器class MacroCommand : public ICommand { public: void Add(std::unique_ptrICommand cmd) { children_.push_back(std::move(cmd)); } void Execute() override { for (auto cmd : children_) { cmd-Execute(); } } void Undo() override { // 注意要逆序撤銷 for (auto it children_.rbegin(); it ! children_.rend(); it) { (*it)-Undo(); } } std::unique_ptrICommand Clone() const override { auto macro std::make_uniqueMacroCommand(); for (auto cmd : children_) { macro-Add(cmd-Clone()); } return macro; } private: std::vectorstd::unique_ptrICommand children_; };這里有一個被無數(shù)人踩過的坑撤銷順序必須逆序。比如先畫線再畫圓撤銷時應(yīng)該先撤銷畫圓再撤銷畫線否則依賴關(guān)系會被破壞。一開始我沒注意這個畫了一個圓又畫一條線撤銷后發(fā)現(xiàn)圓沒被刪掉線卻沒了很困惑。6.2 延遲執(zhí)行與命令隊列很多游戲戰(zhàn)斗系統(tǒng)里技能指令發(fā)出后并不是立刻生效可能要等1秒施法前搖或者進(jìn)入一個戰(zhàn)斗隊列。用命令模式可以很自然地實現(xiàn)先把命令對象放進(jìn)隊列系統(tǒng)在合適時間從隊列頭部取出執(zhí)行。我給一個簡單隊列實現(xiàn)class CommandQueue { public: void Enqueue(std::unique_ptrICommand cmd) { queue_.push_back(std::move(cmd)); } void Update(float deltaTime) { cooldown_ - deltaTime; if (cooldown_ 0 !queue_.empty()) { auto cmd std::move(queue_.front()); queue_.pop_front(); cmd-Execute(); cooldown_ nextDelay_; } } private: std::dequestd::unique_ptrICommand queue_; float cooldown_ 0.0f; float nextDelay_ 1.0f; };這個用法在動畫系統(tǒng)、技能系統(tǒng)、網(wǎng)絡(luò)協(xié)議指令緩沖中都非常常見。關(guān)鍵是命令對象必須保持“待執(zhí)行”狀態(tài)不能被提前執(zhí)行。6.3 日志回放作為調(diào)試工具我之前一直強調(diào)錄制/回放其實在真實項目里更好的用法是做“操作日志回放”來復(fù)現(xiàn)bug。如果你在游戲里遇到一個只有特定操作順序才能觸發(fā)的問題可以讓玩家錄制操作序列導(dǎo)出成文本日志然后把日志解析回相同命令對象在開發(fā)者機(jī)器上一幀一幀回放問題復(fù)現(xiàn)率能提高很多。這個需求我實現(xiàn)過一版。命令類加一個Serialize/Deserialize接口virtual std::string Serialize() const 0; virtual std::unique_ptrICommand Deserialize(const std::string data) 0;這會讓命令模式從“內(nèi)存態(tài)”升級成“可持久化命令流”。這在對戰(zhàn)復(fù)盤、自動化測試?yán)飪r值極高。6.4 與觀察者模式結(jié)合做事件通知很多時候命令執(zhí)行之后UI或者其他模塊需要知道發(fā)生了什么事。我做法是讓命令執(zhí)行時通過事件總線發(fā)一條通知通知里帶上命令名稱和參數(shù)快照。這能讓UI高亮、統(tǒng)計、成就系統(tǒng)等模塊不用侵入業(yè)務(wù)邏輯。結(jié)合方式不復(fù)雜在命令基類里加一個可選的OnExecuted回調(diào)class CommandObserver { public: virtual void OnCommandExecuted(const ICommand cmd) 0; virtual void OnCommandUndone(const ICommand cmd) 0; };Invoker在執(zhí)行/撤銷時遍歷所有觀察者進(jìn)行通知。這樣就把“命令模式”和“觀察者模式”無縫拼接實現(xiàn)解耦。7. 避坑清單與個人心得寫到這里我把自己實戰(zhàn)中總結(jié)的經(jīng)驗濃縮成一份速查清單方便你對照使用提示以下幾點是我反復(fù)踩過的坑建議在動手之前先讀一遍。命令對象里存業(yè)務(wù)參數(shù)不存執(zhí)行中間狀態(tài)中間狀態(tài)由接收者管理。錄制功能一定要用Clone不能用原對象共享。宏回放時如果需要保持undo/redo歷史不被污染單獨設(shè)計“不記錄歷史”的執(zhí)行入口。多步撤銷時按逆序執(zhí)行子命令的Undo。命令類析構(gòu)函數(shù)不要做業(yè)務(wù)操作。盡量用std::unique_ptr管理命令對象生命期需要共享時先想清楚誰能改變命令狀態(tài)。命令歷史要設(shè)上限保留窗口之外的老命令直接丟棄。使用智能指針后要避免對象池和命令對象共存時的不一致問題。Undo和Redo棧要記得在執(zhí)行新命令時清空Redo棧否則會出現(xiàn)“redo到一半然后執(zhí)行新命令”的詭異狀態(tài)。命令基類建議區(qū)分OneShot和Stateful不支持撤銷的命令不要硬塞進(jìn)Undo棧。關(guān)于性能再說兩句。命令模式在C里常被批判為“運行太慢”但這個“慢”通常發(fā)生在你無腦new對象、動輒拷貝大快照的場景下。合理使用對象池、合理設(shè)計快照粒度命令模式在現(xiàn)代C編譯器O2優(yōu)化下性能損失非常小。我實測過在一臺普通機(jī)器上每秒創(chuàng)建并執(zhí)行1萬個輕量命令對象CPU占用率不到2%。所以不要被“新對象慢”這個刻板印象嚇住。最后分享一個心得。我在實際項目里最大的收獲是命令模式不是用來“炫技”的而是用來重新劃清模塊邊界的。當(dāng)你能把“按下按鍵”和“移動角色”解耦成兩個獨立變化的東西之后后續(xù)的錄制、回放、撤銷、網(wǎng)絡(luò)同步都會變得異常順滑。如果你還沒試過在C里系統(tǒng)地用一次命令模式我建議你找一個有具體需求的小項目動手實踐一下比如給控制臺程序加一套undo/redo跑一遍從設(shè)計到實現(xiàn)再到優(yōu)化的完整流程。這個模式對你的設(shè)計能力提升遠(yuǎn)比你背下二十個設(shè)計模式名字要來得實在。