：告別空指針判斷泛濫與if-else沼澤)
你接手一個C項目打開主業(yè)務流程的cpp文件第一眼看到的不是業(yè)務邏輯而是一排又一排的if (xxx nullptr)。再往下翻還有if (result nullptr) return;、if (ptr) ptr-doSomething();。這些空指針守衛(wèi)單看每一條都合理但湊在一起代碼的可讀性、可維護性、測試難度全部亮紅燈。我說的就是空對象模式要解決的問題。它不是一個能用在你所有代碼里的銀彈但它是治理“空指針判斷泛濫”這個問題最直接的工程手段。這篇文章我以C為主要語言把這個模式從概念、實現(xiàn)到實戰(zhàn)坑位完整拆一遍適合正在學設計模式的學生也適合寫業(yè)務系統(tǒng)寫到頭大、想給代碼減負的C開發(fā)。1. 空指針崩潰與if-else沼澤——空對象模式救的是什么1.1 從崩潰到防御式編程先回憶一下沒有空指針檢查的日子。一個系統(tǒng)上線后跑著跑著就崩日志里給出access violation 0xC0000005定位半天發(fā)現(xiàn)是某個回調(diào)接口返回了空指針而調(diào)用方?jīng)]判斷直接解引用進程當場沒了。這個場景在C/C項目里實在太常見尤其是那些要跟C庫、第三方SDK打交道的地方CreateXxx()返回nullptr是常態(tài)。于是團隊開始推行防御式編程規(guī)則很簡單凡是拿到的指針使用前必須先判空。規(guī)則執(zhí)行半年后代碼庫變成另一副模樣。每個函數(shù)開頭都是兩三行守衛(wèi)真正的業(yè)務邏輯被往后擠一個對象如果被多個地方使用每個調(diào)用方都要重復寫一遍判空更煩的是有些人只是“習慣性判空”他自己都不清楚這個指針到底能不能為空于是代碼里充斥著大量永遠走不到的分支。這個階段代碼不會像最開始那樣隨便崩了但維護成本急劇上升。你想在流程里加一個分支先得把那一堆if (p p-IsValid())弄明白你想測試一個模塊發(fā)現(xiàn)構造函數(shù)里有兩個依賴都要傳指針測試里不得不每次構造樁對象。代碼沒有變聰明只是變胖了。1.2 空對象模式把判斷移到對象內(nèi)部空對象模式的核心思想一句話就能說清楚與其在調(diào)用方到處判斷“這個對象是否存在”不如提供一個具有默認行為的“空對象”讓調(diào)用方像使用真實對象一樣使用它。聽起來很簡單但背后的認知轉變很關鍵。傳統(tǒng)的面向對象編程里我們習慣把“對象不存在”表達為“指針為空”然后用if在調(diào)用側處理“不存在”的情況?？諏ο竽Ｊ桨堰@個問題反轉了我不管你傳進來的指針是不是空反正我接到的這個對象一定“存在”只是它可能做的是“什么都不做”或者“返回一個合理的默認值”。舉個最經(jīng)典的生活類比。你家里裝了一個煙霧報警器正常情況它負責檢測煙霧、發(fā)出警報。如果有一天報警器壞了你有兩種處理方式一個是每次出門前都檢查“報警器壞沒壞”壞了就告訴自己“反正壞了不用管”另一個是直接裝一個“啞巴報警器”它永遠不報警但形狀、指示燈、安裝方式跟真的一模一樣你出門時根本不用刻意想它壞沒壞這件事?？諏ο竽Ｊ骄褪沁@個“啞巴報警器”。這個模式在GoF的二十三個設計模式里并沒有被收錄它是后來由Bobby Woolf總結提出的通常被看作策略模式的一個特例。因為“什么都不做”本質上也是一種策略而且往往是最基礎的那個策略。理解這一點很重要你后面看它的變體就會容易很多。2. 動手實現(xiàn)——C空對象模式的完整落地2.1 經(jīng)典多態(tài)方案用NullLogger告別空指針檢查日志系統(tǒng)是空對象模式最經(jīng)典的落地場景幾乎每個項目都適合拿它做第一次實踐。假設我們有一個日志抽象#include iostream #include string class Logger { public: virtual ~Logger() default; virtual void log(const std::string level, const std::string message) 0; }; class ConsoleLogger : public Logger { public: void log(const std::string level, const std::string message) override { std::cout [ level ] message std::endl; } }; class NullLogger final : public Logger { public: void log(const std::string, const std::string) override { // 什么都不做 } };三個關鍵點值得展開。第一基類的析構函數(shù)必須是虛的。這個不用多說了吧你通過基類指針釋放派生類對象的時候非虛析構會導致派生類部分不被正常析構這是未定義行為。C里凡是設計成父接口的類默認就要寫上virtual ~Logger() default。第二NullLogger用final鎖死這是空對象的一個最佳實踐。它本來就是“空”的沒有理由再被繼承出子類鎖死后編譯器還能在部分場合幫你做去虛化優(yōu)化。第三NullLogger::log的參數(shù)故意不寫名字這是告訴你編譯器“我確實不使用這個參數(shù)”避免觸發(fā)-Wunused-parameter警告。有了空對象之后業(yè)務類里對日志的依賴就干凈了class OrderService { Logger logger_; public: explicit OrderService(Logger logger) : logger_(logger) {} void createOrder(int id) { logger_.log(INFO, order start: std::to_string(id)); // 真實業(yè)務邏輯... logger_.log(INFO, order done: std::to_string(id)); } }; int main() { OrderService service(NullLogger{}); service.createOrder(42); return 0; }注意這里我用的是Logger而不是Logger*。這是一個非常重要的設計決定。引用天生不能為空你把空對象模式跟引用結合使用等于從類型系統(tǒng)上徹底消滅了“空指針”這個狀態(tài)。這是C相比Java、C#的一個優(yōu)勢接口能表達得更嚴格。2.2 靜態(tài)多態(tài)方案模板實現(xiàn)的零開銷版本經(jīng)典多態(tài)方案用虛函數(shù)實現(xiàn)運行期通過虛表跳轉。虛函數(shù)在現(xiàn)代CPU上開銷其實很小分支預測一旦命中基本可以忽略。但在某些高性能場景比如游戲引擎每幀要調(diào)用幾百萬次渲染邏輯你依然會對這層間接調(diào)用有顧慮。這時可以用C的模板實現(xiàn)零開銷的空對象。模板方案的核心是把“依賴關系”從運行期搬到了編譯期編譯器在實例化模板時就知道你傳進來的是哪個具體類型虛函數(shù)調(diào)用被直接變成普通函數(shù)調(diào)用甚至內(nèi)聯(lián)template typename LoggerImpl class ServiceTemplate { LoggerImpl logger_; public: explicit ServiceTemplate(LoggerImpl logger) : logger_(logger) {} void process() { logger_.log(DEBUG, static polymorphic service); } }; struct NoopLogger { void log(const std::string, const std::string) {} }; struct StdoutLogger { void log(const std::string level, const std::string msg) { std::cout [ level ] msg std::endl; } }; int main() { NoopLogger nullLogger; ServiceTemplateNoopLogger svc(nullLogger); svc.process(); StdoutLogger realLogger; ServiceTemplateStdoutLogger svc2(realLogger); svc2.process(); }這段代碼里ServiceTemplate根本不關心日志實現(xiàn)長什么樣它只要求傳入的類型具有一個符合log(const std::string, const std::string)簽名的方法。這就是鴨子類型C模板的默認設計哲學。靜態(tài)多態(tài)方案最大的好處是性能最大的代價是類型擦除能力。你不能在運行期動態(tài)切換日志實現(xiàn)因為模板實例化是編譯期決定的。所以我的建議是如果你的空對象選擇是編譯期就能確定的比如某個嵌入式設備固定沒有日志輸出能力那么用模板如果你需要運行期可配置、可插拔用經(jīng)典虛函數(shù)方案。這倆不沖突可以并存。C20還引入了概念concept可以把模板方案做得更嚴謹#include concepts template typename T concept LoggerLike requires(T logger, const std::string msg) { { logger.log(msg) } - std::same_asvoid; }; template LoggerLike T class ServiceConcept { T logger_; public: explicit ServiceConcept(T logger) : logger_(logger) {} void process() { logger_.log(concept logger); } };加了概念約束之后模板報錯信息會比原來友好得多編譯器會直接告訴你“這個類型不滿足LoggerLike這個約束”不是丟出一長串看不懂的模板實例化內(nèi)部錯誤。2.3 單例與生命周期設計工程級改進空對象往往有很多個實例是沒有意義的。一個什么都不做的Logger創(chuàng)建一萬個實例跟一個實例沒有區(qū)別。所以把空對象設計成單例是工程上一個很自然的選擇。C11之后函數(shù)內(nèi)的靜態(tài)局部變量初始化是線程安全的這也讓單例實現(xiàn)變得干凈利落class NullLogger final : public Logger { public: static NullLogger instance() { static NullLogger logger; return logger; } void log(const std::string, const std::string) override {} private: NullLogger() default; };要點有兩處。第一構造函數(shù)是私有的外部不能隨意創(chuàng)建新的NullLogger必須通過instance()獲取。第二static NullLogger logger是magic staticC11起編譯器負責保證線程安全的初始化不需要再加鎖。用的時候OrderService service(NullLogger::instance());注意service構造時持有的是引用它跟NullLogger::instance()返回的這個單例綁定在一起。單例的生命周期是整個程序的生命周期所以不用擔心引用懸空。如果你的項目團隊對單例有潔癖不喜歡全局狀態(tài)那也可以不搞單例直接讓NullLogger是個普通類每個需要它的地方自己構造一個。反正它是空的構造成本接近于零多幾個實例也無所謂。這個取舍沒有絕對的對錯看團隊習慣。3. 實戰(zhàn)演練——用空對象模式重構一段臟代碼3.1 原始代碼滿屏空指針判斷的支付流程空對象模式光看理論很容易覺得“不就是弄個空類嘛”真正上手的價值體現(xiàn)在重構一個復雜業(yè)務分支的時候。下面我模擬一個支付處理流程這種代碼在電商、游戲充值、SaaS計費系統(tǒng)里非常常見class PaymentGateway { public: virtual ~PaymentGateway() default; virtual std::string charge(double amount) 0; virtual bool isAvailable() const 0; }; class PaypalGateway : public PaymentGateway { public: std::string charge(double amount) override { // 真實HTTP調(diào)用省略細節(jié) return success; } bool isAvailable() const override { return true; } }; // 處理支付的業(yè)務邏輯重構前 void ProcessPayment(PaymentGateway* gateway, double amount) { if (gateway nullptr) { std::cout payment skipped: no gateway configured std::endl; return; } if (!gateway-isAvailable()) { std::cout payment gateway unavailable std::endl; return; } std::string result gateway-charge(amount); if (result success) { UpdateOrderStatus(paid); } else { UpdateOrderStatus(failed); } }這已經(jīng)是運氣比較好的情況了只有一個參數(shù)需要判空。真實項目里經(jīng)常是gateway、account、request、callback四個參數(shù)都要判空函數(shù)前半段全是if (xxx nullptr) return;讀代碼的人得屏住呼吸跳到最后才能看到真正的業(yè)務邏輯。這段代碼的問題還不只是可讀性。它把“網(wǎng)關是否配置”“網(wǎng)關是否可用”“扣款是否成功”這三件不同層面的事情全耦合在一個函數(shù)里。如果這個系統(tǒng)上線前沒有配置支付網(wǎng)關那么用戶點了“購買”按鈕代碼只是打了一行日志然后靜默返回用戶前端看到的是“未知錯誤”。這體驗就很奇怪。3.2 重構步驟接口抽象 空對象注入第一步定義支付網(wǎng)關的抽象接口讓“有網(wǎng)關”和“沒網(wǎng)關”都成為這個接口下的合法實現(xiàn)。第二步把原來if (gateway nullptr)分支處理邏輯改成NullPaymentGateway內(nèi)部的“默認行為”。第三步修改業(yè)務函數(shù)入?yún)穆阒羔樃某梢孟麥缈罩羔樑袛?。class NullPaymentGateway final : public PaymentGateway { public: static NullPaymentGateway instance() { static NullPaymentGateway gateway; return gateway; } std::string charge(double) override { return failed; // 沒有網(wǎng)關支付必然失敗 } bool isAvailable() const override { return false; } private: NullPaymentGateway() default; }; void ProcessPayment(PaymentGateway gateway, double amount) { if (!gateway.isAvailable()) { std::cout payment gateway unavailable std::endl; return; } std::string result gateway.charge(amount); if (result success) { UpdateOrderStatus(paid); } else { UpdateOrderStatus(failed); } }調(diào)用方式相應變化// 原先是 ProcessPayment(gatewayPtr, 99.0); // 現(xiàn)在是 PaymentGateway gw (gatewayPtr ! nullptr) ? *gatewayPtr : NullPaymentGateway::instance(); ProcessPayment(gw, 99.0);注意這個封裝通常放在依賴注入的入口處或者工廠函數(shù)內(nèi)部。業(yè)務層不應該再看到裸指針更不應該看到“到底是不是空對象”這個判斷。工廠函數(shù)負責在“沒有真實網(wǎng)關”時返回空對象引用業(yè)務層只面對一個統(tǒng)一的PaymentGateway。重構后業(yè)務函數(shù)的職責變得單一處理支付流程。網(wǎng)關不存在這個狀態(tài)不再散落在業(yè)務分支里而是被封裝在NullPaymentGateway::charge()的返回值里。同時測試也簡單了你不再需要為了讓ProcessPayment跑起來去構造一個真實的Paypal網(wǎng)關。3.3 擴展思考文件系統(tǒng)樹形結構與空節(jié)點支付網(wǎng)關只是空對象模式的入門級應用我再寫一個稍微進階的例子文件系統(tǒng)的樹形結構。Linux里的虛擬文件系統(tǒng)每個目錄項可以是一個普通文件也可以是一個目錄。實際操作中查找文件時經(jīng)常找不到目標傳統(tǒng)的寫法是返回一個空指針shared_ptrNode node FindNode(...); if (node nullptr)。不用空對象模式之前代碼到處是判空。用了空對象模式后可以設計一個NullNodeclass FileNode { public: virtual ~FileNode() default; virtual std::string name() const 0; virtual bool isDirectory() const 0; virtual std::vectorFileNode* children() const 0; }; class NullFileNode final : public FileNode { public: static NullFileNode instance() { static NullFileNode node; return node; } std::string name() const override { return ; } bool isDirectory() const override { return false; } std::vectorFileNode* children() const override { return {}; } private: NullFileNode() default; };現(xiàn)在查找文件的函數(shù)可以聲明為返回FileNode找不到時就返回NullFileNode::instance()。調(diào)用方完全不需要關心“文件是否存在”這件事直接調(diào)用node.name()、node.isDirectory()就行。返回空字符串、空列表是合理的默認行為不會導致崩潰。這里有一個重要的設計經(jīng)驗我要重點說空對象模式下你設計空對象返回的“默認值”必須是語義上合理的而不是機械地返回零值。比如一個查找節(jié)點的場景返回空字符串表示“這個節(jié)點名不存在”就很合理但如果你的業(yè)務會把空字符串當作合法的文件名字符串去參與路徑拼接那空對象反而掩蓋了錯誤。所以空對象模式不是讓你刪掉所有判斷而是把判斷的時機和位置重新規(guī)劃。4. 空對象模式的深水區(qū)——那些沒人告訴你的工程細節(jié)4.1 “空”不等于“什么都不做”默認語義設計剛學空對象模式的人最容易犯的錯誤是把空對象的所有方法都寫成空函數(shù)體。這一聽就不對因為一個真實的對象往往有許多方法其中只有一部分方法在“空”的情況下是合理的“什么都不做”另一些方法必須有返回值而返回什么需要仔細想。舉個例子。你的渲染系統(tǒng)有一個Renderable接口里面有三個方法void Render(),bool IsVisible(),Rect GetBounds()。如果做一個人畜無害的空對象Render()可以空著因為“不繪制”就是你要的效果但IsVisible()和GetBounds()怎么辦瞎返回true和Rect{0,0,0,0}行嗎行但前提是你要想清楚這個默認值在下游怎么被消費。如果下游拿到GetBounds()返回的零矩形去做碰撞檢測那空對象可能把一個“看不見的物體”跟所有東西都碰撞了這就違背了空對象“無害”的初衷。我自己的經(jīng)驗是設計空對象時先列幾個下游關鍵路徑推演一遍默認值在每條路徑上是否安全、是否符合業(yè)務預期。如果推演出來有歧義那就說明這個空對象不適合用在該接口上或者該接口的抽象粒度有問題。另外有些對象的“空”語義是“數(shù)據(jù)不存在”有些是“功能不可用”這兩種不能混用。數(shù)據(jù)不存在返回空容器、空字符串功能不可用返回失敗結果、false要分清楚。NullPaymentGateway::charge()返回“failed”而不是“success”就是功能不可用的語義NullFileNode::name()返回空字符串則是數(shù)據(jù)不存在的語義。4.2 組合優(yōu)于繼承接口爆炸問題的化解經(jīng)典空對象模式高度依賴繼承體系。如果項目里每個服務都對應一個自己的空類那空對象的類數(shù)量會爆炸。比如你有OrderService、UserService、InventoryService每個都要配一個NullOrderService、NullUserService、NullInventoryService維護成本瞬間上來。一個常見的化解思路是用“組合 默認函數(shù)實現(xiàn)”來減少類的數(shù)量。在C里如果基類接口的某些方法帶默認實現(xiàn)派生類就不用再一一重寫。但從空對象模式的本意來說把所有方法都做成空操作本身就是一種壞味道說明這個接口可能被拆小了更好。另一個現(xiàn)實經(jīng)驗是在C里空對象模式往往適合跟抽象工廠、依賴注入容器一起出現(xiàn)。容器注冊接口時如果某個實現(xiàn)沒有配置就注入一個空對象實例。這種集中管理的方式避免了業(yè)務代碼里到處new NullXxx()?？蚣軐用鎺湍銚踝×诉@種復雜性業(yè)務層面拿到統(tǒng)一接口。4.3 與智能指針、依賴注入的配合前面的例子里我一直在用Logger替代Logger*。但現(xiàn)實生產(chǎn)代碼里很多系統(tǒng)還是以shared_ptr傳遞依賴。那空對象模式怎么跟智能指針配合基本思路一樣只是載體變成了智能指針class ServiceWithSharedPtr { std::shared_ptrLogger logger_; public: explicit ServiceWithSharedPtr(std::shared_ptrLogger logger) : logger_(std::move(logger)) { if (!logger_) { logger_ NullLogger::instance(); // 需要 std::shared_ptrLogger } } };但這里有個工程細節(jié)我要強調(diào)NullLogger是單例而shared_ptr默認會嘗試刪除它所管理的對象一個棧上或靜態(tài)存儲期的對象不能直接被shared_ptr管理。有幾個辦法可以繞過去第一種給空對象類提供一個shared_from_this——這要求類繼承enable_shared_from_this單例還是靜態(tài)對象必須保證初始化和存活。第二種用一個靜態(tài)的shared_ptr保存空對象class NullLogger final : public Logger { public: static std::shared_ptrLogger sharedInstance() { static std::shared_ptrLogger instance(new NullLogger()); return instance; } // ... };這樣每個拿到sharedInstance()的人共享同一個控制塊生命周期由靜態(tài)shared_ptr管理。第三種也是我更推薦的構造shared_ptr時傳一個空的刪除器auto nullLogger std::shared_ptrLogger(NullLogger::instance(), [](Logger*){});這種方式下shared_ptr不會真正刪除對象因為對象是靜態(tài)的生命周期是程序級。缺點是空刪除器讓整個控制塊變大一點但對一個單例而言無所謂。從依賴注入的角度看空對象跟“可選依賴”的區(qū)別值得說一下。可選依賴是有些環(huán)境有有些環(huán)境沒有沒有的時候就給空對象。但有些依賴是“必須存在”的只是當前測試環(huán)境里不存在這時空對象模式不能用來掩蓋錯誤。一個支付系統(tǒng)在測試環(huán)境沒有真實網(wǎng)關你把NullPaymentGateway注入進去一切看起來正常直到上線后才發(fā)現(xiàn)業(yè)務邏輯里所有失敗路徑都沒有被正確處理?？諏ο竽Ｊ椒浅Ｈ菀妆划敵伞鞍褑栴}藏著”的工具這是它最大的工程風險。4.4 性能與編譯期權衡虛函數(shù)還是模板關于空對象模式的性能我做一個比較系統(tǒng)的說明。經(jīng)典多態(tài)空對象每次方法調(diào)用是一次間接虛函數(shù)調(diào)用?，F(xiàn)代CPU的分支預測器對穩(wěn)定的虛調(diào)用預測能力很強所以大多數(shù)業(yè)務場景下性能差異可以忽略。但在兩個場景下虛函數(shù)會產(chǎn)生可感知的開銷一種是低延遲交易、游戲引擎、信號處理這類每幀/每秒調(diào)用百萬次以上的熱路徑另一種是空對象的方法本身是空的理論上編譯器有機會把整個調(diào)用優(yōu)化掉但因為虛函數(shù)的存在跨編譯單元的虛調(diào)用無法內(nèi)聯(lián)優(yōu)化落空。模板方案靜態(tài)多態(tài)的性能優(yōu)勢就在這。模板實例化后NoopLogger::log()是編譯期已知的如果函數(shù)體為空編譯器可以直接把整個調(diào)用折疊掉。對于熱路徑這個優(yōu)勢是絕對的。如果項目需要熱切換空對象和真實實現(xiàn)不能完全靜態(tài)編譯那還有一條折中路線用if constexpr配合編譯期開關。比如游戲引擎里有一個ENABLE_FOG_OF_WAR宏FogVisibility這個抽象在編譯期根據(jù)宏決定是空實現(xiàn)還是有實現(xiàn)。這樣最差情況也只是編譯期的分支運行期沒有多余開銷。選擇建議依賴數(shù)量少、調(diào)用頻率低隨便用經(jīng)典多態(tài)簡單清晰。依賴數(shù)量多、調(diào)用頻率高優(yōu)先模板空對象哪怕犧牲一點類型擦除能力。既有熱切換需求又要性能用if constexpr或代碼生成控制避免運行期虛調(diào)用。5. 常見問題與模式邊界速查5.1 七個高頻問題速查表空對象模式的使用者我看下來普遍會踩下面七個坑做成一張表給你們參考。問題原因建議空對象方法全寫空函數(shù)體沒有分析默認值語義逐個方法推演下游行為空方法要符合業(yè)務預期空對象當單例但被shared_ptr管理生命周期錯亂用空刪除器或靜態(tài)shared_ptr基類接口太大空對象被迫實現(xiàn)一堆無意義方法拆分接口空對象只面對職責單一的小接口空對象被當作“錯誤隱藏器”掩蓋了配置缺失等真實問題區(qū)分“可選依賴”和“必選依賴”后者不要用空對象調(diào)用方仍然寫if (isNull())空對象和真實對象的差異暴露給上層用工廠/依賴注入封裝空對象的選擇邏輯空對象與真實對象行為不一致異常復雜模板方法太多簡化接口把空對象納入策略模式統(tǒng)一設計用optional替代一切空對象需求optional和價值類型不是一回事能無則用optional有接口多態(tài)則用空對象5.2 與Optional、策略模式的邊界很多人會把空對象模式和C17的std::optional搞混因為它們都處理“沒有值”的情況。它們的區(qū)別可以這樣理解optional是數(shù)據(jù)層面的“沒有值”它是一個值包裝器你得顯式判斷有沒有值然后才能取出里面的內(nèi)容來調(diào)用方法空對象模式是行為層面的“沒有實現(xiàn)”它本身就是一個完整的對象只是提供的行為是無害的默認行為。代碼上的對比更直觀// 用 optional你仍然要判空 std::optionalLogger* maybeLogger GetLogger(); if (maybeLogger.has_value()) { maybeLogger.value()-log(INFO, hello); } // 用空對象無需判斷 Logger logger GetLogger(); // 內(nèi)部返回 NullLogger::instance() logger.log(INFO, hello);optional適合表示“結果可能沒有”的返回值比如查找、解析空對象模式適合表示“依賴可能缺失”的運行環(huán)境比如日志、配置、外部服務。二者不是競爭關系可以配合使用。optional可以看作是空對象模式的底層工具空對象可以讓內(nèi)部用optional或variant實現(xiàn)更復雜的邏輯。和策略模式的關系前面的文中已經(jīng)提過。策略模式定義一組可互換的算法族空對象模式是其中的一個特例只不過那個策略恰好是“什么都不做”或者“返回默認值”。Duck類型和空對象模版方式結合時空對象甚至可以沒有公共基類只要有相同的方法簽名即可。5.3 什么時候不該用空對象模式最后說點反話?？諏ο竽Ｊ讲皇亲屇阍诖a里消滅所有判空有些場景它只會幫倒忙。第一當一個操作在“空”狀態(tài)下必須產(chǎn)生業(yè)務告警時千萬別用空對象覆蓋。比如扣款失敗必須通知財務核對你用了一個NullPaymentGateway讓支付靜默失敗財務永遠不知道發(fā)生了什么。這種場景需要的是顯式錯誤處理而不是“無害”的空對象。第二當調(diào)用方需要區(qū)分“對象不存在”和“對象存在但狀態(tài)異?！睍r空對象會模糊這兩者的差異。比如某個配置項的空對象表示“沒有配置”但真實對象也可能因為加載失敗而處于“不可用”狀態(tài)這時空對象沒法表達后一種情況。第三當接口的方法之間有先后約束或者狀態(tài)關聯(lián)時空對象的實現(xiàn)會非常別扭。比如Begin()和End()必須成對調(diào)用空對象在Begin()里什么都不做后面End()也沒法判斷要不要清理這種接口不適合空對象模式。第四性能極端敏感且無法利用模板靜態(tài)優(yōu)化時虛函數(shù)調(diào)用哪怕一個周期都是浪費這時候直接考慮判空提前返回反而更實在?？諏ο竽Ｊ降谋举|是把“對象是否存在”的復雜度從調(diào)用方轉移到了被調(diào)用方。它的前提是這個轉移是值得的是符合業(yè)務表達的。一旦轉移之后反而把錯誤藏起來、把語義搞模糊那這個模式就用錯了。最后聊幾句實踐經(jīng)驗我在真實項目里用空對象模式最成功的一次是在一個內(nèi)部組件里引入NullMetricsReporter。當時系統(tǒng)有很多可選的數(shù)據(jù)上報通道有的環(huán)境有監(jiān)控體系有的環(huán)境什么都沒有。之前代碼里每個上報點都要先if (reporter ! nullptr)重構后統(tǒng)一注入MetricsReporter測試環(huán)境直接綁定NullMetricsReporter::instance()代碼量減少四分之一而且新同事上手時不會再問“這個reporter會不會是空”。這是這個模式最好的一種使用方式當一個接口只是流程中的一個配角時用一個默認沉默的實現(xiàn)把它撐起來讓主流程專注在它真正關心的業(yè)務上。反過來我也見過把空對象模式用崩的案例上層把空對象注入到必選依賴里然后業(yè)務出問題時完全無跡可尋。所以用之前先問自己一句這里的空到底是“本來就可以是空”還是“現(xiàn)在恰好是空”前者適合空對象后者需要你在調(diào)用側顯式處理。這個問題想清楚了空對象模式就是C工具箱里一把非常順手的改錐想不清楚它就是一塊藏在業(yè)務沙發(fā)下的積木遲早踩到。 C++空對象模式實戰(zhàn)：告別空指針判斷泛濫與if-else沼澤
你接手一個C項目打開主業(yè)務流程的cpp文件第一眼看到的不是業(yè)務邏輯而是一排又一排的if (xxx nullptr)。再往下翻還有if (result nullptr) return;、if (ptr) ptr-doSomething();。這些空指針守衛(wèi)單看每一條都合理但湊在一起代碼的可讀性、可維護性、測試難度全部亮紅燈。我說的就是空對象模式要解決的問題。它不是一個能用在你所有代碼里的銀彈但它是治理“空指針判斷泛濫”這個問題最直接的工程手段。這篇文章我以C為主要語言把這個模式從概念、實現(xiàn)到實戰(zhàn)坑位完整拆一遍適合正在學設計模式的學生也適合寫業(yè)務系統(tǒng)寫到頭大、想給代碼減負的C開發(fā)。1. 空指針崩潰與if-else沼澤——空對象模式救的是什么1.1 從崩潰到防御式編程先回憶一下沒有空指針檢查的日子。一個系統(tǒng)上線后跑著跑著就崩日志里給出access violation 0xC0000005定位半天發(fā)現(xiàn)是某個回調(diào)接口返回了空指針而調(diào)用方?jīng)]判斷直接解引用進程當場沒了。這個場景在C/C項目里實在太常見尤其是那些要跟C庫、第三方SDK打交道的地方CreateXxx()返回nullptr是常態(tài)。于是團隊開始推行防御式編程規(guī)則很簡單凡是拿到的指針使用前必須先判空。規(guī)則執(zhí)行半年后代碼庫變成另一副模樣。每個函數(shù)開頭都是兩三行守衛(wèi)真正的業(yè)務邏輯被往后擠一個對象如果被多個地方使用每個調(diào)用方都要重復寫一遍判空更煩的是有些人只是“習慣性判空”他自己都不清楚這個指針到底能不能為空于是代碼里充斥著大量永遠走不到的分支。這個階段代碼不會像最開始那樣隨便崩了但維護成本急劇上升。你想在流程里加一個分支先得把那一堆if (p p-IsValid())弄明白你想測試一個模塊發(fā)現(xiàn)構造函數(shù)里有兩個依賴都要傳指針測試里不得不每次構造樁對象。代碼沒有變聰明只是變胖了。1.2 空對象模式把判斷移到對象內(nèi)部空對象模式的核心思想一句話就能說清楚與其在調(diào)用方到處判斷“這個對象是否存在”不如提供一個具有默認行為的“空對象”讓調(diào)用方像使用真實對象一樣使用它。聽起來很簡單但背后的認知轉變很關鍵。傳統(tǒng)的面向對象編程里我們習慣把“對象不存在”表達為“指針為空”然后用if在調(diào)用側處理“不存在”的情況?？諏ο竽Ｊ桨堰@個問題反轉了我不管你傳進來的指針是不是空反正我接到的這個對象一定“存在”只是它可能做的是“什么都不做”或者“返回一個合理的默認值”。舉個最經(jīng)典的生活類比。你家里裝了一個煙霧報警器正常情況它負責檢測煙霧、發(fā)出警報。如果有一天報警器壞了你有兩種處理方式一個是每次出門前都檢查“報警器壞沒壞”壞了就告訴自己“反正壞了不用管”另一個是直接裝一個“啞巴報警器”它永遠不報警但形狀、指示燈、安裝方式跟真的一模一樣你出門時根本不用刻意想它壞沒壞這件事?？諏ο竽Ｊ骄褪沁@個“啞巴報警器”。這個模式在GoF的二十三個設計模式里并沒有被收錄它是后來由Bobby Woolf總結提出的通常被看作策略模式的一個特例。因為“什么都不做”本質上也是一種策略而且往往是最基礎的那個策略。理解這一點很重要你后面看它的變體就會容易很多。2. 動手實現(xiàn)——C空對象模式的完整落地2.1 經(jīng)典多態(tài)方案用NullLogger告別空指針檢查日志系統(tǒng)是空對象模式最經(jīng)典的落地場景幾乎每個項目都適合拿它做第一次實踐。假設我們有一個日志抽象#include iostream #include string class Logger { public: virtual ~Logger() default; virtual void log(const std::string level, const std::string message) 0; }; class ConsoleLogger : public Logger { public: void log(const std::string level, const std::string message) override { std::cout [ level ] message std::endl; } }; class NullLogger final : public Logger { public: void log(const std::string, const std::string) override { // 什么都不做 } };三個關鍵點值得展開。第一基類的析構函數(shù)必須是虛的。這個不用多說了吧你通過基類指針釋放派生類對象的時候非虛析構會導致派生類部分不被正常析構這是未定義行為。C里凡是設計成父接口的類默認就要寫上virtual ~Logger() default。第二NullLogger用final鎖死這是空對象的一個最佳實踐。它本來就是“空”的沒有理由再被繼承出子類鎖死后編譯器還能在部分場合幫你做去虛化優(yōu)化。第三NullLogger::log的參數(shù)故意不寫名字這是告訴你編譯器“我確實不使用這個參數(shù)”避免觸發(fā)-Wunused-parameter警告。有了空對象之后業(yè)務類里對日志的依賴就干凈了class OrderService { Logger logger_; public: explicit OrderService(Logger logger) : logger_(logger) {} void createOrder(int id) { logger_.log(INFO, order start: std::to_string(id)); // 真實業(yè)務邏輯... logger_.log(INFO, order done: std::to_string(id)); } }; int main() { OrderService service(NullLogger{}); service.createOrder(42); return 0; }注意這里我用的是Logger而不是Logger*。這是一個非常重要的設計決定。引用天生不能為空你把空對象模式跟引用結合使用等于從類型系統(tǒng)上徹底消滅了“空指針”這個狀態(tài)。這是C相比Java、C#的一個優(yōu)勢接口能表達得更嚴格。2.2 靜態(tài)多態(tài)方案模板實現(xiàn)的零開銷版本經(jīng)典多態(tài)方案用虛函數(shù)實現(xiàn)運行期通過虛表跳轉。虛函數(shù)在現(xiàn)代CPU上開銷其實很小分支預測一旦命中基本可以忽略。但在某些高性能場景比如游戲引擎每幀要調(diào)用幾百萬次渲染邏輯你依然會對這層間接調(diào)用有顧慮。這時可以用C的模板實現(xiàn)零開銷的空對象。模板方案的核心是把“依賴關系”從運行期搬到了編譯期編譯器在實例化模板時就知道你傳進來的是哪個具體類型虛函數(shù)調(diào)用被直接變成普通函數(shù)調(diào)用甚至內(nèi)聯(lián)template typename LoggerImpl class ServiceTemplate { LoggerImpl logger_; public: explicit ServiceTemplate(LoggerImpl logger) : logger_(logger) {} void process() { logger_.log(DEBUG, static polymorphic service); } }; struct NoopLogger { void log(const std::string, const std::string) {} }; struct StdoutLogger { void log(const std::string level, const std::string msg) { std::cout [ level ] msg std::endl; } }; int main() { NoopLogger nullLogger; ServiceTemplateNoopLogger svc(nullLogger); svc.process(); StdoutLogger realLogger; ServiceTemplateStdoutLogger svc2(realLogger); svc2.process(); }這段代碼里ServiceTemplate根本不關心日志實現(xiàn)長什么樣它只要求傳入的類型具有一個符合log(const std::string, const std::string)簽名的方法。這就是鴨子類型C模板的默認設計哲學。靜態(tài)多態(tài)方案最大的好處是性能最大的代價是類型擦除能力。你不能在運行期動態(tài)切換日志實現(xiàn)因為模板實例化是編譯期決定的。所以我的建議是如果你的空對象選擇是編譯期就能確定的比如某個嵌入式設備固定沒有日志輸出能力那么用模板如果你需要運行期可配置、可插拔用經(jīng)典虛函數(shù)方案。這倆不沖突可以并存。C20還引入了概念concept可以把模板方案做得更嚴謹#include concepts template typename T concept LoggerLike requires(T logger, const std::string msg) { { logger.log(msg) } - std::same_asvoid; }; template LoggerLike T class ServiceConcept { T logger_; public: explicit ServiceConcept(T logger) : logger_(logger) {} void process() { logger_.log(concept logger); } };加了概念約束之后模板報錯信息會比原來友好得多編譯器會直接告訴你“這個類型不滿足LoggerLike這個約束”不是丟出一長串看不懂的模板實例化內(nèi)部錯誤。2.3 單例與生命周期設計工程級改進空對象往往有很多個實例是沒有意義的。一個什么都不做的Logger創(chuàng)建一萬個實例跟一個實例沒有區(qū)別。所以把空對象設計成單例是工程上一個很自然的選擇。C11之后函數(shù)內(nèi)的靜態(tài)局部變量初始化是線程安全的這也讓單例實現(xiàn)變得干凈利落class NullLogger final : public Logger { public: static NullLogger instance() { static NullLogger logger; return logger; } void log(const std::string, const std::string) override {} private: NullLogger() default; };要點有兩處。第一構造函數(shù)是私有的外部不能隨意創(chuàng)建新的NullLogger必須通過instance()獲取。第二static NullLogger logger是magic staticC11起編譯器負責保證線程安全的初始化不需要再加鎖。用的時候OrderService service(NullLogger::instance());注意service構造時持有的是引用它跟NullLogger::instance()返回的這個單例綁定在一起。單例的生命周期是整個程序的生命周期所以不用擔心引用懸空。如果你的項目團隊對單例有潔癖不喜歡全局狀態(tài)那也可以不搞單例直接讓NullLogger是個普通類每個需要它的地方自己構造一個。反正它是空的構造成本接近于零多幾個實例也無所謂。這個取舍沒有絕對的對錯看團隊習慣。3. 實戰(zhàn)演練——用空對象模式重構一段臟代碼3.1 原始代碼滿屏空指針判斷的支付流程空對象模式光看理論很容易覺得“不就是弄個空類嘛”真正上手的價值體現(xiàn)在重構一個復雜業(yè)務分支的時候。下面我模擬一個支付處理流程這種代碼在電商、游戲充值、SaaS計費系統(tǒng)里非常常見class PaymentGateway { public: virtual ~PaymentGateway() default; virtual std::string charge(double amount) 0; virtual bool isAvailable() const 0; }; class PaypalGateway : public PaymentGateway { public: std::string charge(double amount) override { // 真實HTTP調(diào)用省略細節(jié) return success; } bool isAvailable() const override { return true; } }; // 處理支付的業(yè)務邏輯重構前 void ProcessPayment(PaymentGateway* gateway, double amount) { if (gateway nullptr) { std::cout payment skipped: no gateway configured std::endl; return; } if (!gateway-isAvailable()) { std::cout payment gateway unavailable std::endl; return; } std::string result gateway-charge(amount); if (result success) { UpdateOrderStatus(paid); } else { UpdateOrderStatus(failed); } }這已經(jīng)是運氣比較好的情況了只有一個參數(shù)需要判空。真實項目里經(jīng)常是gateway、account、request、callback四個參數(shù)都要判空函數(shù)前半段全是if (xxx nullptr) return;讀代碼的人得屏住呼吸跳到最后才能看到真正的業(yè)務邏輯。這段代碼的問題還不只是可讀性。它把“網(wǎng)關是否配置”“網(wǎng)關是否可用”“扣款是否成功”這三件不同層面的事情全耦合在一個函數(shù)里。如果這個系統(tǒng)上線前沒有配置支付網(wǎng)關那么用戶點了“購買”按鈕代碼只是打了一行日志然后靜默返回用戶前端看到的是“未知錯誤”。這體驗就很奇怪。3.2 重構步驟接口抽象 空對象注入第一步定義支付網(wǎng)關的抽象接口讓“有網(wǎng)關”和“沒網(wǎng)關”都成為這個接口下的合法實現(xiàn)。第二步把原來if (gateway nullptr)分支處理邏輯改成NullPaymentGateway內(nèi)部的“默認行為”。第三步修改業(yè)務函數(shù)入?yún)穆阒羔樃某梢孟麥缈罩羔樑袛?。class NullPaymentGateway final : public PaymentGateway { public: static NullPaymentGateway instance() { static NullPaymentGateway gateway; return gateway; } std::string charge(double) override { return failed; // 沒有網(wǎng)關支付必然失敗 } bool isAvailable() const override { return false; } private: NullPaymentGateway() default; }; void ProcessPayment(PaymentGateway gateway, double amount) { if (!gateway.isAvailable()) { std::cout payment gateway unavailable std::endl; return; } std::string result gateway.charge(amount); if (result success) { UpdateOrderStatus(paid); } else { UpdateOrderStatus(failed); } }調(diào)用方式相應變化// 原先是 ProcessPayment(gatewayPtr, 99.0); // 現(xiàn)在是 PaymentGateway gw (gatewayPtr ! nullptr) ? *gatewayPtr : NullPaymentGateway::instance(); ProcessPayment(gw, 99.0);注意這個封裝通常放在依賴注入的入口處或者工廠函數(shù)內(nèi)部。業(yè)務層不應該再看到裸指針更不應該看到“到底是不是空對象”這個判斷。工廠函數(shù)負責在“沒有真實網(wǎng)關”時返回空對象引用業(yè)務層只面對一個統(tǒng)一的PaymentGateway。重構后業(yè)務函數(shù)的職責變得單一處理支付流程。網(wǎng)關不存在這個狀態(tài)不再散落在業(yè)務分支里而是被封裝在NullPaymentGateway::charge()的返回值里。同時測試也簡單了你不再需要為了讓ProcessPayment跑起來去構造一個真實的Paypal網(wǎng)關。3.3 擴展思考文件系統(tǒng)樹形結構與空節(jié)點支付網(wǎng)關只是空對象模式的入門級應用我再寫一個稍微進階的例子文件系統(tǒng)的樹形結構。Linux里的虛擬文件系統(tǒng)每個目錄項可以是一個普通文件也可以是一個目錄。實際操作中查找文件時經(jīng)常找不到目標傳統(tǒng)的寫法是返回一個空指針shared_ptrNode node FindNode(...); if (node nullptr)。不用空對象模式之前代碼到處是判空。用了空對象模式后可以設計一個NullNodeclass FileNode { public: virtual ~FileNode() default; virtual std::string name() const 0; virtual bool isDirectory() const 0; virtual std::vectorFileNode* children() const 0; }; class NullFileNode final : public FileNode { public: static NullFileNode instance() { static NullFileNode node; return node; } std::string name() const override { return ; } bool isDirectory() const override { return false; } std::vectorFileNode* children() const override { return {}; } private: NullFileNode() default; };現(xiàn)在查找文件的函數(shù)可以聲明為返回FileNode找不到時就返回NullFileNode::instance()。調(diào)用方完全不需要關心“文件是否存在”這件事直接調(diào)用node.name()、node.isDirectory()就行。返回空字符串、空列表是合理的默認行為不會導致崩潰。這里有一個重要的設計經(jīng)驗我要重點說空對象模式下你設計空對象返回的“默認值”必須是語義上合理的而不是機械地返回零值。比如一個查找節(jié)點的場景返回空字符串表示“這個節(jié)點名不存在”就很合理但如果你的業(yè)務會把空字符串當作合法的文件名字符串去參與路徑拼接那空對象反而掩蓋了錯誤。所以空對象模式不是讓你刪掉所有判斷而是把判斷的時機和位置重新規(guī)劃。4. 空對象模式的深水區(qū)——那些沒人告訴你的工程細節(jié)4.1 “空”不等于“什么都不做”默認語義設計剛學空對象模式的人最容易犯的錯誤是把空對象的所有方法都寫成空函數(shù)體。這一聽就不對因為一個真實的對象往往有許多方法其中只有一部分方法在“空”的情況下是合理的“什么都不做”另一些方法必須有返回值而返回什么需要仔細想。舉個例子。你的渲染系統(tǒng)有一個Renderable接口里面有三個方法void Render(),bool IsVisible(),Rect GetBounds()。如果做一個人畜無害的空對象Render()可以空著因為“不繪制”就是你要的效果但IsVisible()和GetBounds()怎么辦瞎返回true和Rect{0,0,0,0}行嗎行但前提是你要想清楚這個默認值在下游怎么被消費。如果下游拿到GetBounds()返回的零矩形去做碰撞檢測那空對象可能把一個“看不見的物體”跟所有東西都碰撞了這就違背了空對象“無害”的初衷。我自己的經(jīng)驗是設計空對象時先列幾個下游關鍵路徑推演一遍默認值在每條路徑上是否安全、是否符合業(yè)務預期。如果推演出來有歧義那就說明這個空對象不適合用在該接口上或者該接口的抽象粒度有問題。另外有些對象的“空”語義是“數(shù)據(jù)不存在”有些是“功能不可用”這兩種不能混用。數(shù)據(jù)不存在返回空容器、空字符串功能不可用返回失敗結果、false要分清楚。NullPaymentGateway::charge()返回“failed”而不是“success”就是功能不可用的語義NullFileNode::name()返回空字符串則是數(shù)據(jù)不存在的語義。4.2 組合優(yōu)于繼承接口爆炸問題的化解經(jīng)典空對象模式高度依賴繼承體系。如果項目里每個服務都對應一個自己的空類那空對象的類數(shù)量會爆炸。比如你有OrderService、UserService、InventoryService每個都要配一個NullOrderService、NullUserService、NullInventoryService維護成本瞬間上來。一個常見的化解思路是用“組合 默認函數(shù)實現(xiàn)”來減少類的數(shù)量。在C里如果基類接口的某些方法帶默認實現(xiàn)派生類就不用再一一重寫。但從空對象模式的本意來說把所有方法都做成空操作本身就是一種壞味道說明這個接口可能被拆小了更好。另一個現(xiàn)實經(jīng)驗是在C里空對象模式往往適合跟抽象工廠、依賴注入容器一起出現(xiàn)。容器注冊接口時如果某個實現(xiàn)沒有配置就注入一個空對象實例。這種集中管理的方式避免了業(yè)務代碼里到處new NullXxx()?？蚣軐用鎺湍銚踝×诉@種復雜性業(yè)務層面拿到統(tǒng)一接口。4.3 與智能指針、依賴注入的配合前面的例子里我一直在用Logger替代Logger*。但現(xiàn)實生產(chǎn)代碼里很多系統(tǒng)還是以shared_ptr傳遞依賴。那空對象模式怎么跟智能指針配合基本思路一樣只是載體變成了智能指針class ServiceWithSharedPtr { std::shared_ptrLogger logger_; public: explicit ServiceWithSharedPtr(std::shared_ptrLogger logger) : logger_(std::move(logger)) { if (!logger_) { logger_ NullLogger::instance(); // 需要 std::shared_ptrLogger } } };但這里有個工程細節(jié)我要強調(diào)NullLogger是單例而shared_ptr默認會嘗試刪除它所管理的對象一個棧上或靜態(tài)存儲期的對象不能直接被shared_ptr管理。有幾個辦法可以繞過去第一種給空對象類提供一個shared_from_this——這要求類繼承enable_shared_from_this單例還是靜態(tài)對象必須保證初始化和存活。第二種用一個靜態(tài)的shared_ptr保存空對象class NullLogger final : public Logger { public: static std::shared_ptrLogger sharedInstance() { static std::shared_ptrLogger instance(new NullLogger()); return instance; } // ... };這樣每個拿到sharedInstance()的人共享同一個控制塊生命周期由靜態(tài)shared_ptr管理。第三種也是我更推薦的構造shared_ptr時傳一個空的刪除器auto nullLogger std::shared_ptrLogger(NullLogger::instance(), [](Logger*){});這種方式下shared_ptr不會真正刪除對象因為對象是靜態(tài)的生命周期是程序級。缺點是空刪除器讓整個控制塊變大一點但對一個單例而言無所謂。從依賴注入的角度看空對象跟“可選依賴”的區(qū)別值得說一下。可選依賴是有些環(huán)境有有些環(huán)境沒有沒有的時候就給空對象。但有些依賴是“必須存在”的只是當前測試環(huán)境里不存在這時空對象模式不能用來掩蓋錯誤。一個支付系統(tǒng)在測試環(huán)境沒有真實網(wǎng)關你把NullPaymentGateway注入進去一切看起來正常直到上線后才發(fā)現(xiàn)業(yè)務邏輯里所有失敗路徑都沒有被正確處理?？諏ο竽Ｊ椒浅Ｈ菀妆划敵伞鞍褑栴}藏著”的工具這是它最大的工程風險。4.4 性能與編譯期權衡虛函數(shù)還是模板關于空對象模式的性能我做一個比較系統(tǒng)的說明。經(jīng)典多態(tài)空對象每次方法調(diào)用是一次間接虛函數(shù)調(diào)用?，F(xiàn)代CPU的分支預測器對穩(wěn)定的虛調(diào)用預測能力很強所以大多數(shù)業(yè)務場景下性能差異可以忽略。但在兩個場景下虛函數(shù)會產(chǎn)生可感知的開銷一種是低延遲交易、游戲引擎、信號處理這類每幀/每秒調(diào)用百萬次以上的熱路徑另一種是空對象的方法本身是空的理論上編譯器有機會把整個調(diào)用優(yōu)化掉但因為虛函數(shù)的存在跨編譯單元的虛調(diào)用無法內(nèi)聯(lián)優(yōu)化落空。模板方案靜態(tài)多態(tài)的性能優(yōu)勢就在這。模板實例化后NoopLogger::log()是編譯期已知的如果函數(shù)體為空編譯器可以直接把整個調(diào)用折疊掉。對于熱路徑這個優(yōu)勢是絕對的。如果項目需要熱切換空對象和真實實現(xiàn)不能完全靜態(tài)編譯那還有一條折中路線用if constexpr配合編譯期開關。比如游戲引擎里有一個ENABLE_FOG_OF_WAR宏FogVisibility這個抽象在編譯期根據(jù)宏決定是空實現(xiàn)還是有實現(xiàn)。這樣最差情況也只是編譯期的分支運行期沒有多余開銷。選擇建議依賴數(shù)量少、調(diào)用頻率低隨便用經(jīng)典多態(tài)簡單清晰。依賴數(shù)量多、調(diào)用頻率高優(yōu)先模板空對象哪怕犧牲一點類型擦除能力。既有熱切換需求又要性能用if constexpr或代碼生成控制避免運行期虛調(diào)用。5. 常見問題與模式邊界速查5.1 七個高頻問題速查表空對象模式的使用者我看下來普遍會踩下面七個坑做成一張表給你們參考。問題原因建議空對象方法全寫空函數(shù)體沒有分析默認值語義逐個方法推演下游行為空方法要符合業(yè)務預期空對象當單例但被shared_ptr管理生命周期錯亂用空刪除器或靜態(tài)shared_ptr基類接口太大空對象被迫實現(xiàn)一堆無意義方法拆分接口空對象只面對職責單一的小接口空對象被當作“錯誤隱藏器”掩蓋了配置缺失等真實問題區(qū)分“可選依賴”和“必選依賴”后者不要用空對象調(diào)用方仍然寫if (isNull())空對象和真實對象的差異暴露給上層用工廠/依賴注入封裝空對象的選擇邏輯空對象與真實對象行為不一致異常復雜模板方法太多簡化接口把空對象納入策略模式統(tǒng)一設計用optional替代一切空對象需求optional和價值類型不是一回事能無則用optional有接口多態(tài)則用空對象5.2 與Optional、策略模式的邊界很多人會把空對象模式和C17的std::optional搞混因為它們都處理“沒有值”的情況。它們的區(qū)別可以這樣理解optional是數(shù)據(jù)層面的“沒有值”它是一個值包裝器你得顯式判斷有沒有值然后才能取出里面的內(nèi)容來調(diào)用方法空對象模式是行為層面的“沒有實現(xiàn)”它本身就是一個完整的對象只是提供的行為是無害的默認行為。代碼上的對比更直觀// 用 optional你仍然要判空 std::optionalLogger* maybeLogger GetLogger(); if (maybeLogger.has_value()) { maybeLogger.value()-log(INFO, hello); } // 用空對象無需判斷 Logger logger GetLogger(); // 內(nèi)部返回 NullLogger::instance() logger.log(INFO, hello);optional適合表示“結果可能沒有”的返回值比如查找、解析空對象模式適合表示“依賴可能缺失”的運行環(huán)境比如日志、配置、外部服務。二者不是競爭關系可以配合使用。optional可以看作是空對象模式的底層工具空對象可以讓內(nèi)部用optional或variant實現(xiàn)更復雜的邏輯。和策略模式的關系前面的文中已經(jīng)提過。策略模式定義一組可互換的算法族空對象模式是其中的一個特例只不過那個策略恰好是“什么都不做”或者“返回默認值”。Duck類型和空對象模版方式結合時空對象甚至可以沒有公共基類只要有相同的方法簽名即可。5.3 什么時候不該用空對象模式最后說點反話?？諏ο竽Ｊ讲皇亲屇阍诖a里消滅所有判空有些場景它只會幫倒忙。第一當一個操作在“空”狀態(tài)下必須產(chǎn)生業(yè)務告警時千萬別用空對象覆蓋。比如扣款失敗必須通知財務核對你用了一個NullPaymentGateway讓支付靜默失敗財務永遠不知道發(fā)生了什么。這種場景需要的是顯式錯誤處理而不是“無害”的空對象。第二當調(diào)用方需要區(qū)分“對象不存在”和“對象存在但狀態(tài)異?！睍r空對象會模糊這兩者的差異。比如某個配置項的空對象表示“沒有配置”但真實對象也可能因為加載失敗而處于“不可用”狀態(tài)這時空對象沒法表達后一種情況。第三當接口的方法之間有先后約束或者狀態(tài)關聯(lián)時空對象的實現(xiàn)會非常別扭。比如Begin()和End()必須成對調(diào)用空對象在Begin()里什么都不做后面End()也沒法判斷要不要清理這種接口不適合空對象模式。第四性能極端敏感且無法利用模板靜態(tài)優(yōu)化時虛函數(shù)調(diào)用哪怕一個周期都是浪費這時候直接考慮判空提前返回反而更實在?？諏ο竽Ｊ降谋举|是把“對象是否存在”的復雜度從調(diào)用方轉移到了被調(diào)用方。它的前提是這個轉移是值得的是符合業(yè)務表達的。一旦轉移之后反而把錯誤藏起來、把語義搞模糊那這個模式就用錯了。最后聊幾句實踐經(jīng)驗我在真實項目里用空對象模式最成功的一次是在一個內(nèi)部組件里引入NullMetricsReporter。當時系統(tǒng)有很多可選的數(shù)據(jù)上報通道有的環(huán)境有監(jiān)控體系有的環(huán)境什么都沒有。之前代碼里每個上報點都要先if (reporter ! nullptr)重構后統(tǒng)一注入MetricsReporter測試環(huán)境直接綁定NullMetricsReporter::instance()代碼量減少四分之一而且新同事上手時不會再問“這個reporter會不會是空”。這是這個模式最好的一種使用方式當一個接口只是流程中的一個配角時用一個默認沉默的實現(xiàn)把它撐起來讓主流程專注在它真正關心的業(yè)務上。反過來我也見過把空對象模式用崩的案例上層把空對象注入到必選依賴里然后業(yè)務出問題時完全無跡可尋。所以用之前先問自己一句這里的空到底是“本來就可以是空”還是“現(xiàn)在恰好是空”前者適合空對象后者需要你在調(diào)用側顯式處理。這個問題想清楚了空對象模式就是C工具箱里一把非常順手的改錐想不清楚它就是一塊藏在業(yè)務沙發(fā)下的積木遲早踩到。