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