寫這篇的時候其實我猶豫了一下要不要再寫設計模式。市面上講工廠模式的文章一抓一大把從GOF的經典定義到各種C重造輪子的博客實在不算新鮮。但我在實際項目里審了幾年代碼發(fā)現(xiàn)一個挺有意思的現(xiàn)象真正把工廠方法用對、用到位的人不多大多數(shù)人只是背了個概念甚至把簡單工廠和工廠方法混為一談。很多人一上來就在基類構造函數(shù)里調虛函數(shù)——這是C特有的坑后面我會專門講。所以這篇不打算從頭抄一遍GOF的UML圖而是想從“你在代碼里感受到了什么痛點自然而然走到這個模式門前”的角度來聊。先說明白這個模式到底解決了哪類問題再手把手帶著把代碼寫出來然后講幾個很容易踩碎的細節(jié)最后聊聊現(xiàn)在C新標準下這個經典模式有什么新的表達方式。1. 判定需求膨脹的代碼壞味道switch-case和if-else的重災區(qū)很多模式不是“設計”出來的是被逼出來的。工廠方法最典型的出現(xiàn)場景是代碼里開始出現(xiàn)大量根據(jù)類型標記分支的邏輯而且這些邏輯還在不斷增長。1.1 一個很現(xiàn)實的例子模擬對象創(chuàng)建器假設你在寫一個性能分析工具需要把各個監(jiān)控指標對應的模擬對象創(chuàng)建出來。一開始只有CPU和內存兩個指標代碼很清爽// 粗暴但清晰的第一版 std::shared_ptrSimObject CreateSimulator(const std::string type) { if (type CPU) { return std::make_sharedCpuSimulator(); } if (type MEM) { return std::make_sharedMemSimulator(); } return nullptr; }加個判斷多簡單但是項目永遠是活的。第二周加了磁盤IO第三周加了網絡流量第四周銷售那邊提了個新需求說模擬場景里要包含一組容器化的指標對象。于是函數(shù)開始變長if (type DISK) { ... } if (type NET) { ... } if (type CONTAINER) { return std::make_sharedContainerGroupSimulator(); }每個新增的類型都會讓這個函數(shù)多兩三行?？粗€行但問題不在于這個函數(shù)本身而在于使用這個創(chuàng)建函數(shù)的每個地方幾乎也都有一套對應的分支邏輯。比如初始化模擬對象參數(shù)的地方if (type CPU) { params.SetCpuQuota(...); } else if (type MEM) { params.SetMemLimit(...); }配置加載的地方再判斷一次if (type CPU) { config.RegisterMetric(cycles); } else if (type DISK) { config.RegisterMetric(io_wait); }你發(fā)現(xiàn)沒有創(chuàng)建邏輯和類型分支像癌細胞一樣擴散到了調用方的各個環(huán)節(jié)。每次新增一個模擬對象不是改一處而是到處打補丁。這時候你會產生一種典型的“代碼壞味”感受我什么都沒干我只是想加點功能為什么要把以前寫的東西全都翻出來改一遍這就是需求膨脹到一定階段后很典型的“開放-封閉原則”失效場景。所謂面向修改開放、面向擴展封閉在最初的簡單代碼里只是一個美好愿望而分支點在不斷累積的時候就是該考慮系統(tǒng)收斂一下對象創(chuàng)建這件事了。1.2 層層疊疊的分支邏輯為什么讓大家痛苦再往深了說這套分支邏輯真正讓人難受的點有三個一是邏輯重復。每個調用點都要判斷類型標記同樣的判斷字符串散落在各處一旦命名規(guī)范變了比如把“MEM”改為“MEMORY”你得全局搜索替換稍不留神就有遺漏。二是耦合點太密。模塊A在創(chuàng)建對象模塊B在用對象模塊C在配置對象一旦鏈條底層的模擬對象構造簽名改了所有分支里的調用代碼都要跟著改。三是測試成本高。想單測一個新增的模擬對象你得先把主分支函數(shù)跑起來但主分支函數(shù)本身就承擔了所有類型的分發(fā)根本沒法單獨測。而且一旦設計出多處分支結構你還會發(fā)現(xiàn)一個更麻煩的事分支之外的公共流程被夾碎了。比如每個模擬對象創(chuàng)建完都要經過初始化、綁定數(shù)據(jù)源、注冊到管理器這套“公共骨架”被散落在分支之間難以抽取復用。感性的描述說了這么多其實核心已經浮出來了我們真正想做的就是讓每類對象知道自己該怎么被創(chuàng)建并且在新增類型時不再回頭修改舊代碼。2. 工廠方法模式的核心本質推遲實例化到子類好了上面這些痛點如果你也經歷過那你其實已經準備好理解這個模式了。工廠方法模式不是一組稀奇古怪的類名堆砌它的本質只有一句話定義一個創(chuàng)建對象的接口讓子類決定實例化哪一個類。2.1 把“創(chuàng)建一個對象”也當成一門產品來做先看兩個最核心的概念Product產品和 Creator創(chuàng)建者。Product是“產品”的統(tǒng)稱在實際代碼里就是那個所有具體對象都要實現(xiàn)的抽象基類或協(xié)議接口。Creator是“創(chuàng)建者”它本身并不關心你到底要生產哪個具體產品它只定義了創(chuàng)建產品時需要的那幾步公共骨架其中有一部關鍵動作是“請求一個產品實例”這個關鍵動作就叫工廠方法Factory Method。粗看會覺得它很簡單因為GOF原書里給的類圖看起來就是兩個層級——一個Product層級一個Creator層級。但真正值得琢磨的是C實現(xiàn)里那個“生產得到的到底是啥”的問題因為工廠方法返回類型恰恰是C里看上去簡單、卻很容易搞錯重點的地方。2.2 C中為什么基類指針/引用至關重要在C里談工廠方法有一個必須首先牢固建立的概念工廠方法返回的必須是一個抽象類型基類指針或引用而絕不能是具體類型。這不是什么風格偏好而是C的靜態(tài)類型系統(tǒng)所決定的。比如方法簽名寫著std::shared_ptrSimObject Create(const std::string type)里面的SimObject就是咱們的抽象基類。這樣子類覆蓋工廠方法時返回的才可能是CpuSimulator、MemSimulator這樣的具體產品。調用方只和基類接口打交道具體類型在編譯期被“抹掉”了這就是多態(tài)在創(chuàng)建層面的體現(xiàn)。反過來想如果工廠方法直接返回具體類型比如CpuSimulator*那你創(chuàng)建函數(shù)就得為每個具體類型寫一個重載調用方的分支判斷還會變成編譯期的類型選擇一套組合拳下來代碼反而比一開始更擰巴。所以記住一個C特有結論工廠方法模式的前提是能在運行時拿到基類指針而用它去調用虛函數(shù)時調用的是具體型號的方法。不在這個前提下談工廠方法等于建了一棟沒有承重墻的房子。3. 手寫一套工廠方法的完整骨架一個C示例的逐步推導光講概念沒有用這里咱們直接從一個“波形生成器”的示例開始完整過一遍代碼的演進。之所以用波形生成器是因為它足夠簡單又能體現(xiàn)“不同產品不同參數(shù)”的特點非常適合做案例。3.1 從Product到Creator的代碼推導先定義產品抽象。#include memory #include string #include vector // 產品基類所有波形生成器都遵循這個接口 class WaveGenerator { public: virtual ~WaveGenerator() default; // 每種波形生成器都會生成自己的采樣點序列 virtual std::vectordouble Generate(int sampleCount) const 0; // 每種波形都有自己的標識名方便調試和序列化 virtual std::string GetName() const 0; };然后是幾個具體產品class SineWaveGenerator final : public WaveGenerator { public: std::vectordouble Generate(int sampleCount) const override { std::vectordouble data; data.reserve(sampleCount); for (int i 0; i sampleCount; i) { data.push_back(std::sin(2.0 * 3.141592653589793 * i / sampleCount)); } return data; } std::string GetName() const override { return sine; } }; class SquareWaveGenerator final : public WaveGenerator { public: std::vectordouble Generate(int sampleCount) const override { std::vectordouble data; data.reserve(sampleCount); for (int i 0; i sampleCount; i) { double t static_castdouble(i) / sampleCount; data.push_back(t 0.5 ? 1.0 : -1.0); } return data; } std::string GetName() const override { return square; } };好現(xiàn)在產品有了。接下來定義Creator。注意這里的關鍵是Creator不是負責具體分發(fā)的那一個它只負責提供一個可以覆蓋的“生產入口”class WaveFactory { public: virtual ~WaveFactory() default; // 工廠方法子類決定返回哪種具體產品 virtual std::unique_ptrWaveGenerator CreateWave() const 0; // 一個使用了工廠方法的公共流程 // 不管子類生產的是正弦波還是方波公共流程都是一樣的 void GenerateAndPrint(int sampleCount) const { auto wave CreateWave(); auto samples wave-Generate(sampleCount); std::cout Generated wave-GetName() with samples.size() samples: std::endl; for (double v : samples) { std::cout v ; } std::cout std::endl; } };然后在具體工廠里各自決定自己生產什么class SineWaveFactory final : public WaveFactory { public: std::unique_ptrWaveGenerator CreateWave() const override { return std::make_uniqueSineWaveGenerator(); } }; class SquareWaveFactory final : public WaveFactory { public: std::unique_ptrWaveGenerator CreateWave() const override { return std::make_uniqueSquareWaveGenerator(); } };到這一步我估計有經驗的開發(fā)者已經發(fā)現(xiàn)了這個“工廠”和常見的“把type字符串丟進去返回對應對象”的那種寫法不太一樣。它沒有if分支甚至沒有一個集中式的分發(fā)邏輯。是的這就是工廠方法模式和簡單工廠的核心差別返回什么東西這件事被下放到了子類里而不是保留在一個集中函數(shù)里。3.2 調用方式與動態(tài)類型識別的小技巧調用方式倒是很簡單int main() { SineWaveFactory sineFactory; sineFactory.GenerateAndPrint(16); SquareWaveFactory squareFactory; squareFactory.GenerateAndPrint(16); }這個輸出會展示正弦波和方波各自的采樣數(shù)據(jù)。很多初學C的同學會糾結一個問題CreateWave返回的是unique_ptrWaveGenerator那我怎么知道它底層到底是一個正弦波還是方波這個問題得分兩說。如果產品接口設計得足夠完善調用方壓根不需要關心具體類型只需要對著基類接口操作。如果你真的有必要知道具體類型——比如要下發(fā)給不同處理鏈路的模塊——那么應當走到工廠方法之外去思考設計問題產品的職責邊界是不是沒劃分干凈是否所有波形生成器都真的適合跑在同一個抽象下這種情況通常意味著接口里缺少一個能區(qū)分行為差異的虛函數(shù)。還有一個細節(jié)在工廠方法里返回unique_ptr和返回shared_ptr其實是兩種不同的語義選擇。前者表示創(chuàng)建者并不共享對象所有權誰調用誰獨占后者表示這個產物可能被多個持有者同時引用。實際項目里如果產品的生命周期和調用方深度綁定unique_ptr更合適因為可以避免無謂的引用計數(shù)開銷如果產品將來會被多個模塊共享shared_ptr才是合理選擇。3.3 關鍵“為什么”公共流程代碼如何復用現(xiàn)在再回頭看WaveFactory::GenerateAndPrint你會發(fā)現(xiàn)它其實是個模版方法Template Method的影子。工廠方法模式通常和模版方法配合使用——基類定義完整流程把其中一個步驟創(chuàng)建產品延遲到子類實現(xiàn)。這樣每個子類雖然工廠方法內容不同但上層流程完全一致。很多人忽略了這個配合關系只盯著工廠方法本身導致寫出來的代碼仍然是“每個子類重復一套公共流程”。而 C 里復用公共流程最自然的方式就是把這個流程放在基類非虛函數(shù)中需要變化的那一步調用純虛函數(shù)。這個組合設計能讓代碼的復用程度顯著提升也是我想強調的一個比較實用的技巧。4. 怎么比“C默認行為”多做一步返回類型拷貝問題的避坑手冊這部分是C里最容易把人繞暈的地方我單獨拿出來展開說。因為工廠方法涉及返回一個對象而這個對象需要穿過函數(shù)返回值這道“邊界”。4.1 為什么基類返回類型不能直接返回具體對象如果直接寫WaveGenerator CreateWave() const; // 錯那你的產品對象在返回的瞬間就會被切片slicing。所謂切片就是子類對象按基類類型的值返回時編譯器會構造一個WaveGenerator臨時對象而子類部分的數(shù)據(jù)被丟棄。這在靜態(tài)類型語言里是很容易犯的低級錯誤尤其對于從Java轉C的開發(fā)者來說因為Java里一切引用本質上都是指針語義不會有這種問題。C的正確做法前面已經寫過了返回指針或引用。引用返回有個生命周期風險工廠方法一般返回本地的局部對象如果返回引用就會變成一個懸空引用。所以現(xiàn)代C里最安全的默認選擇就是返回unique_ptr或者shared_ptr。4.2 基類必須聲明虛析構函數(shù)原因和解決辦法這個其實是老生常談但它在工廠方法里有個特別致命的場景值得單獨強調。想想看你從工廠方法里拿到了一個unique_ptrWaveGenerator底層實際是SineWaveGenerator。在銷毀這個對象時unique_ptrWaveGenerator的析構函數(shù)會調用WaveGenerator的析構函數(shù)。如果WaveGenerator的析構函數(shù)不是虛函數(shù)那它就不會再去調用SineWaveGenerator的析構函數(shù)于是子類里持有的資源可能不會被釋放。在波形生成器這種簡單場景里可能問題不大但如果子類持有文件句柄、網絡連接或者自己分配的大塊緩沖這個問題就立刻變成內存泄漏。解決辦法也很簡單在產品基類的析構函數(shù)前面加個virtualvirtual ~WaveGenerator() default;一定要記住沒有虛析構函數(shù)的基類就不能被作為工廠方法的返回類型來用。這不是風格問題是安全底線。4.3 構造函數(shù)里調用工廠方法C虛調用的致命坑這里插一個我在真實代碼評審里見過的經典錯誤。有一位同事在一個模擬器框架里把工廠方法的調用放在基類的構造函數(shù)里期望在構造基類時就能動態(tài)創(chuàng)建出具體的產品。結果程序運行后產品永遠是一個“空殼”類型的實例。這個問題的根因在C的構造順序里在基類構造函數(shù)執(zhí)行期間虛函數(shù)表指向的仍然是基類的虛函數(shù)版本。也就是說C的虛函數(shù)多態(tài)機制在構造期間還沒有完全生效。你在構造函數(shù)里調用CreateWave()即使它被聲明為虛函數(shù)當前調用的仍然只會是WaveFactory::CreateWave()—— 而基類里那個純虛函數(shù)根本沒法被調用能編譯運行純粹是因為某些寫法兜住了但行為完全不對。正確做法是不要在構造函數(shù)里調用虛函數(shù)。把創(chuàng)建動作移動到獨立的方法里讓它在對象完全構造成功后再被觸發(fā)。這也是工廠方法存在于“創(chuàng)建對象”這個語境下的一個側面提醒——它適合在產品對象已經被完整構造之后對某個接口發(fā)起“生產”請求而不是在構造過程中自找麻煩。5. 三種容易混淆的工廠形態(tài)簡單工廠、工廠方法、抽象工廠的實際選擇很多人把“工廠”這個詞當作一個萬能藥遇到創(chuàng)建邏輯有點復雜就往工廠里套。其實光C社區(qū)里就至少流傳著三種不一樣工廠形態(tài)把它們區(qū)分清楚在做設計決策時會有幫助。5.1 三個形態(tài)的本質對比先看簡單工廠它的特征是有一個集中的CreateXxx靜態(tài)函數(shù)接收一個參數(shù)然后根據(jù)參數(shù)開關分發(fā)到不同的具體構造函數(shù)。這個不算GOF里的經典模式而是一種編碼慣例但它最常見幾乎所有做C的人都會先寫這個。再看工廠方法就是前面一直在講的它把創(chuàng)建動作定義在基類里具體生產交給子類。最后是抽象工廠它不是一兩個類而是一整套產品族創(chuàng)建接口。比如圖形界面庫里你有一個“Windows風格工廠”能同時創(chuàng)建按鈕、文本框、滾動條還有一個“Linux風格工廠”也創(chuàng)建同簽名的三個控件只是每個控件的實現(xiàn)完全不同。這里的核心是產品族之間的配套一致性。它們三者的關系我習慣用一個表格來總結形態(tài)創(chuàng)建入口核心特點適用場景簡單工廠集中式靜態(tài)函數(shù)靠條件分支創(chuàng)建產品擴展需改原函數(shù)產品類型少、變化不頻繁的小項目工廠方法基類虛函數(shù)子類實現(xiàn)每個子類決定自己的產品符合封閉/開放原則產品種類會持續(xù)擴展創(chuàng)建流程相對統(tǒng)一抽象工廠一組創(chuàng)建接口按產品族實現(xiàn)保證產品族內部一致性復雜度和靈活度都高多套風格/系列的產品同時存在啟動時選一整套5.2 實際項目里如何選擇別為設計而設計我的經驗是不要一上來就抽象工廠大部分項目用到工廠方法就夠了。如果一個系統(tǒng)只需要支持兩三種固定的產品類型簡單工廠反而更直接——你不需要建立那么多繼承關系也不需要一個虛函數(shù)表跳來跳去。但一旦你預見到“產品類型每周都可能增加一類”而且每一類的創(chuàng)建方式都有其特殊性那簡單工廠的分支就會開始膨脹。這時切換到工廠方法新增類型只需要新增一個產品類和對應的工廠子類老代碼一行不動。另外的一個參考指標是看創(chuàng)建流程的骨架是否穩(wěn)定。如果創(chuàng)建一個對象總是要經過“解析配置—構造內部組件—綁定外部依賴—注冊回調”這幾步而具體每一步各家不同那么工廠方法配合模版方法結構就非常合適。如果連流程骨架本身都不穩(wěn)定每個產品類型的生命周期和管理方式都大相徑庭那再用工廠硬套只會讓代碼更擰巴——這時候可以直接在更高層級用一個注冊表 委托函數(shù)的路子了。6. C工程里的實際擴展注冊表工廠和lambda工廠傳統(tǒng)工廠方法模式是依賴繼承來解決問題的但在現(xiàn)代C里工程上還有兩種很常見的變體注冊表工廠和lambda工廠。它們不是設計模式的新概念而是利用語言特性對工廠方法模式的適配。6.1 注冊表工廠用映射表替代一大堆子類如果你有幾十種產品為每一個產品都寫一個工廠子類會顯得特別冗余。這時用一個注冊表把字符串和std::function映射起來能讓代碼干凈得多#include functional #include unordered_map class WaveRegistry { public: using FactoryFn std::functionstd::unique_ptrWaveGenerator(); void Register(const std::string name, FactoryFn fn) { factories_[name] std::move(fn); } std::unique_ptrWaveGenerator Create(const std::string name) const { auto it factories_.find(name); if (it factories_.end()) { return nullptr; } return it-second(); } private: std::unordered_mapstd::string, FactoryFn factories_; };然后你就可以在某個模塊初始化時把具體創(chuàng)建函數(shù)注冊進去WaveRegistry registry; registry.Register(sine, []() - std::unique_ptrWaveGenerator { return std::make_uniqueSineWaveGenerator(); }); registry.Register(square, []() - std::unique_ptrWaveGenerator { return std::make_uniqueSquareWaveGenerator(); });調用側只需要知道名稱完全不接觸任何具體工廠類。這種方式對插件化、動態(tài)加載特別友好因為每個插件只需要把自己支持的類型注冊進去就行不需要改主程序里的任何分發(fā)邏輯。在實際工程里這是我在處理“產品類型非常多”時最常用的方式。6.2 lambda工廠的簡潔邊界還有一種更輕量的用法就是干脆不建工廠類直接在需要創(chuàng)建產品的地方用lambda寫一個創(chuàng)建函數(shù)。這個方式適合那種“只在一個地方創(chuàng)建、其他地方不關心”的場景——比如某個服務內部構建自己的依賴組件時直接寫個lambda作為默認工廠即可。lambda工廠的邊界在于它不適合“工廠本身需要復用”的場景也不適合產品創(chuàng)建流程較長、需要子類共享骨架的場景。如果創(chuàng)建邏輯只有兩三行而且不會在第二處復用我支持你用lambda一旦創(chuàng)建過程超過十行或者你發(fā)現(xiàn)這個lambda要在三個以上地方被調用那就該冷靜下來把它升格為真正的類或注冊表條目。7. 現(xiàn)代C語境下的工廠方法演進智能指針與移動語義的配合C已經從裸指針時代走過來了工廠方法模式也搭上了新特性的快車。最明顯的變化是返回值的所有權語義被大大強化。7.1 從裸指針到unique_ptr/shared_ptr的變遷老式的C工廠方法通常返回一個裸指針注釋里寫著“調用者負責delete”。這套約定在現(xiàn)代C里已經基本被淘汰原因很簡單所有權不明確容易漏刪也難以表達是獨占還是共享?，F(xiàn)在的主流寫法是以std::unique_ptr或std::shared_ptr作為返回類型。unique_ptr表示明確的獨占所有權移動語義讓返回值在函數(shù)間傳遞幾乎零開銷shared_ptr則適用于產品會被多個模塊共享的場景。一個小貼士在C14/17里如果產品類型繼承自enable_shared_from_this那么建議直接用shared_ptr作為工廠返回類型否則后續(xù)再轉成shared_ptr時容易遇到所有權割裂的問題。7.2 移動語義和完美轉發(fā)對工廠方法的影響移動語義讓工廠方法里構造產品對象的開銷進一步下降。比如產品內部持有很大的緩沖區(qū)C11之前可能需要拷貝整個緩沖區(qū)現(xiàn)在直接移動即可std::unique_ptrBufferGenerator CreateBufferGenerator(std::vectordouble data) { auto gen std::make_uniqueBufferGenerator(); gen-SetData(std::move(data)); // 不再拷貝 return gen; }完美轉發(fā)則讓工廠方法可以接受任意參數(shù)并原樣轉發(fā)給構造函數(shù)。這在有些復雜產品初始化時很方便template typename... Args std::unique_ptrWaveGenerator CreateWrapped(Args... args) { return std::make_uniqueSineWaveGenerator(std::forwardArgs(args)...); }但要留意一下編譯器的模板理解和報錯信息C模板報錯自古就繞。對這種代碼重要建議是給工廠方法加上概念約束(concepts)或至少在注釋里寫清楚參數(shù)含義否則三個月后你自己都會忘記這些Args該怎么傳。7.3 C20/23的新工具讓工廠方法更健壯在C20和C23里我比較關注兩個特性在工廠方法上的應用。一個是concepts可以用它來約束產品類型必須繼承自WaveGenerator在編譯期就攔截不匹配的類型template DerivedFromWaveGenerator T std::unique_ptrWaveGenerator CreateAsWave() { return std::make_uniqueT(); }另一個是std::expected或std::optional它們讓工廠方法的“創(chuàng)建失敗”語義更清晰。比如注冊表工廠里找不到對應類型時以前返回nullptr調用方還得判空現(xiàn)在可以把錯誤原因一道返回。雖然會增加一點模板復雜度但對大型項目頗有幫助。8. 測試與調試心得工廠方法在實踐里的隱藏價值最后這部分說說工廠方法給測試和調試帶來的便利以及在真實項目中它的另一個“隱形好處”。8.1 便于單元測試的依賴注入點如果你的所有模擬對象都通過工廠方法創(chuàng)建那么在測試時你可以輕易地替換掉整個產品子樹。比如你要測GenerateAndPrint這個公共流程不需要真的創(chuàng)建正弦波只要用一個測試專用的假工廠讓它返回一個記錄型的假產品就足夠了。生產代碼和測試代碼之間通過工廠接口對接耦合度控制得很好。這也解釋了為什么很多優(yōu)秀的C測試框架里mock對象幾乎都依賴工廠或抽象接口——因為只有基于接口編程才能在運行時替換依賴。8.2 一個調試排錯的具體案例詭異的產品類型錯亂有一次我在調試一套渲染引擎發(fā)現(xiàn)場景中的某個物體偶爾會表現(xiàn)出完全不屬于自己類型的渲染行為。排查了很久最后定位到是工廠方法里返回了錯誤的類型轉換。當時的代碼類似于return std::make_sharedSomeDerived(...);但由于基類的工廠方法簽名是返回基類類型而子類的工廠方法里寫了一塊不正確的類型轉換邏輯導致運行時拿到的是一個類型不匹配的實例。這類問題如果不用工廠模式而直接在各調用方創(chuàng)建對象往往會被埋得更深。工廠方法把“創(chuàng)建”這一層面統(tǒng)一收口后定位起來反而容易很多。8.3 工廠方法模式給你帶來的全局視角我自己覺得工廠方法模式真正的價值在于它強迫你把“創(chuàng)建”這件事當成一個完整的、可擴展的關卡。每一個產品不再是散落在系統(tǒng)各處的new或者make_unique而是有明確入口、有明確職責、有明確測試點的組件。這會讓整個系統(tǒng)的結構邊界清晰起來——無論你是自己維護一個中等規(guī)模的項目還是在團隊里協(xié)作這種邊界感對降低維護成本的作用遠超模式本身。9. 最后再分享一個經驗從簡單工廠到工廠方法的平滑重構路徑如果你現(xiàn)在的代碼還是一個簡單的集中式CreateByType函數(shù)別急著推倒重來平滑重構路徑很關鍵。第一步先把創(chuàng)建入口修正為返回std::unique_ptrWaveGenerator而不是裸指針——這是所有權語義的明確化。第二步把函數(shù)改造成基類的虛函數(shù)讓每個分支對應一個子類。這一步不需要一次做完可以先讓最常用的幾個類型走子類路線其他類型仍保留在基類里做兜底。第三步逐步把“按類型分發(fā)”的邏輯從調用方中移除讓所有調用方只看基類接口不再關心具體類型。最后再考慮是否引入注冊表或lambda工廠判斷標準是子類數(shù)量是否多到了寫起來很累的程度。這樣重構的好處是每一步都是可編譯、可測試的不會出現(xiàn)推倒重來的大跨度失敗。我一直覺得設計模式不是拿來炫耀詞匯量的而是拿來讓明天的自己少掉點頭發(fā)的。如果你手頭正有一個分支發(fā)散得很難受的創(chuàng)建邏輯不妨試試這個路徑。寫完最后一行你多半會跟我一樣覺得那點重構的功夫真值。 C++工廠方法模式深度解析：從分支重構到智能指針實踐
寫這篇的時候其實我猶豫了一下要不要再寫設計模式。市面上講工廠模式的文章一抓一大把從GOF的經典定義到各種C重造輪子的博客實在不算新鮮。但我在實際項目里審了幾年代碼發(fā)現(xiàn)一個挺有意思的現(xiàn)象真正把工廠方法用對、用到位的人不多大多數(shù)人只是背了個概念甚至把簡單工廠和工廠方法混為一談。很多人一上來就在基類構造函數(shù)里調虛函數(shù)——這是C特有的坑后面我會專門講。所以這篇不打算從頭抄一遍GOF的UML圖而是想從“你在代碼里感受到了什么痛點自然而然走到這個模式門前”的角度來聊。先說明白這個模式到底解決了哪類問題再手把手帶著把代碼寫出來然后講幾個很容易踩碎的細節(jié)最后聊聊現(xiàn)在C新標準下這個經典模式有什么新的表達方式。1. 判定需求膨脹的代碼壞味道switch-case和if-else的重災區(qū)很多模式不是“設計”出來的是被逼出來的。工廠方法最典型的出現(xiàn)場景是代碼里開始出現(xiàn)大量根據(jù)類型標記分支的邏輯而且這些邏輯還在不斷增長。1.1 一個很現(xiàn)實的例子模擬對象創(chuàng)建器假設你在寫一個性能分析工具需要把各個監(jiān)控指標對應的模擬對象創(chuàng)建出來。一開始只有CPU和內存兩個指標代碼很清爽// 粗暴但清晰的第一版 std::shared_ptrSimObject CreateSimulator(const std::string type) { if (type CPU) { return std::make_sharedCpuSimulator(); } if (type MEM) { return std::make_sharedMemSimulator(); } return nullptr; }加個判斷多簡單但是項目永遠是活的。第二周加了磁盤IO第三周加了網絡流量第四周銷售那邊提了個新需求說模擬場景里要包含一組容器化的指標對象。于是函數(shù)開始變長if (type DISK) { ... } if (type NET) { ... } if (type CONTAINER) { return std::make_sharedContainerGroupSimulator(); }每個新增的類型都會讓這個函數(shù)多兩三行?？粗€行但問題不在于這個函數(shù)本身而在于使用這個創(chuàng)建函數(shù)的每個地方幾乎也都有一套對應的分支邏輯。比如初始化模擬對象參數(shù)的地方if (type CPU) { params.SetCpuQuota(...); } else if (type MEM) { params.SetMemLimit(...); }配置加載的地方再判斷一次if (type CPU) { config.RegisterMetric(cycles); } else if (type DISK) { config.RegisterMetric(io_wait); }你發(fā)現(xiàn)沒有創(chuàng)建邏輯和類型分支像癌細胞一樣擴散到了調用方的各個環(huán)節(jié)。每次新增一個模擬對象不是改一處而是到處打補丁。這時候你會產生一種典型的“代碼壞味”感受我什么都沒干我只是想加點功能為什么要把以前寫的東西全都翻出來改一遍這就是需求膨脹到一定階段后很典型的“開放-封閉原則”失效場景。所謂面向修改開放、面向擴展封閉在最初的簡單代碼里只是一個美好愿望而分支點在不斷累積的時候就是該考慮系統(tǒng)收斂一下對象創(chuàng)建這件事了。1.2 層層疊疊的分支邏輯為什么讓大家痛苦再往深了說這套分支邏輯真正讓人難受的點有三個一是邏輯重復。每個調用點都要判斷類型標記同樣的判斷字符串散落在各處一旦命名規(guī)范變了比如把“MEM”改為“MEMORY”你得全局搜索替換稍不留神就有遺漏。二是耦合點太密。模塊A在創(chuàng)建對象模塊B在用對象模塊C在配置對象一旦鏈條底層的模擬對象構造簽名改了所有分支里的調用代碼都要跟著改。三是測試成本高。想單測一個新增的模擬對象你得先把主分支函數(shù)跑起來但主分支函數(shù)本身就承擔了所有類型的分發(fā)根本沒法單獨測。而且一旦設計出多處分支結構你還會發(fā)現(xiàn)一個更麻煩的事分支之外的公共流程被夾碎了。比如每個模擬對象創(chuàng)建完都要經過初始化、綁定數(shù)據(jù)源、注冊到管理器這套“公共骨架”被散落在分支之間難以抽取復用。感性的描述說了這么多其實核心已經浮出來了我們真正想做的就是讓每類對象知道自己該怎么被創(chuàng)建并且在新增類型時不再回頭修改舊代碼。2. 工廠方法模式的核心本質推遲實例化到子類好了上面這些痛點如果你也經歷過那你其實已經準備好理解這個模式了。工廠方法模式不是一組稀奇古怪的類名堆砌它的本質只有一句話定義一個創(chuàng)建對象的接口讓子類決定實例化哪一個類。2.1 把“創(chuàng)建一個對象”也當成一門產品來做先看兩個最核心的概念Product產品和 Creator創(chuàng)建者。Product是“產品”的統(tǒng)稱在實際代碼里就是那個所有具體對象都要實現(xiàn)的抽象基類或協(xié)議接口。Creator是“創(chuàng)建者”它本身并不關心你到底要生產哪個具體產品它只定義了創(chuàng)建產品時需要的那幾步公共骨架其中有一部關鍵動作是“請求一個產品實例”這個關鍵動作就叫工廠方法Factory Method。粗看會覺得它很簡單因為GOF原書里給的類圖看起來就是兩個層級——一個Product層級一個Creator層級。但真正值得琢磨的是C實現(xiàn)里那個“生產得到的到底是啥”的問題因為工廠方法返回類型恰恰是C里看上去簡單、卻很容易搞錯重點的地方。2.2 C中為什么基類指針/引用至關重要在C里談工廠方法有一個必須首先牢固建立的概念工廠方法返回的必須是一個抽象類型基類指針或引用而絕不能是具體類型。這不是什么風格偏好而是C的靜態(tài)類型系統(tǒng)所決定的。比如方法簽名寫著std::shared_ptrSimObject Create(const std::string type)里面的SimObject就是咱們的抽象基類。這樣子類覆蓋工廠方法時返回的才可能是CpuSimulator、MemSimulator這樣的具體產品。調用方只和基類接口打交道具體類型在編譯期被“抹掉”了這就是多態(tài)在創(chuàng)建層面的體現(xiàn)。反過來想如果工廠方法直接返回具體類型比如CpuSimulator*那你創(chuàng)建函數(shù)就得為每個具體類型寫一個重載調用方的分支判斷還會變成編譯期的類型選擇一套組合拳下來代碼反而比一開始更擰巴。所以記住一個C特有結論工廠方法模式的前提是能在運行時拿到基類指針而用它去調用虛函數(shù)時調用的是具體型號的方法。不在這個前提下談工廠方法等于建了一棟沒有承重墻的房子。3. 手寫一套工廠方法的完整骨架一個C示例的逐步推導光講概念沒有用這里咱們直接從一個“波形生成器”的示例開始完整過一遍代碼的演進。之所以用波形生成器是因為它足夠簡單又能體現(xiàn)“不同產品不同參數(shù)”的特點非常適合做案例。3.1 從Product到Creator的代碼推導先定義產品抽象。#include memory #include string #include vector // 產品基類所有波形生成器都遵循這個接口 class WaveGenerator { public: virtual ~WaveGenerator() default; // 每種波形生成器都會生成自己的采樣點序列 virtual std::vectordouble Generate(int sampleCount) const 0; // 每種波形都有自己的標識名方便調試和序列化 virtual std::string GetName() const 0; };然后是幾個具體產品class SineWaveGenerator final : public WaveGenerator { public: std::vectordouble Generate(int sampleCount) const override { std::vectordouble data; data.reserve(sampleCount); for (int i 0; i sampleCount; i) { data.push_back(std::sin(2.0 * 3.141592653589793 * i / sampleCount)); } return data; } std::string GetName() const override { return sine; } }; class SquareWaveGenerator final : public WaveGenerator { public: std::vectordouble Generate(int sampleCount) const override { std::vectordouble data; data.reserve(sampleCount); for (int i 0; i sampleCount; i) { double t static_castdouble(i) / sampleCount; data.push_back(t 0.5 ? 1.0 : -1.0); } return data; } std::string GetName() const override { return square; } };好現(xiàn)在產品有了。接下來定義Creator。注意這里的關鍵是Creator不是負責具體分發(fā)的那一個它只負責提供一個可以覆蓋的“生產入口”class WaveFactory { public: virtual ~WaveFactory() default; // 工廠方法子類決定返回哪種具體產品 virtual std::unique_ptrWaveGenerator CreateWave() const 0; // 一個使用了工廠方法的公共流程 // 不管子類生產的是正弦波還是方波公共流程都是一樣的 void GenerateAndPrint(int sampleCount) const { auto wave CreateWave(); auto samples wave-Generate(sampleCount); std::cout Generated wave-GetName() with samples.size() samples: std::endl; for (double v : samples) { std::cout v ; } std::cout std::endl; } };然后在具體工廠里各自決定自己生產什么class SineWaveFactory final : public WaveFactory { public: std::unique_ptrWaveGenerator CreateWave() const override { return std::make_uniqueSineWaveGenerator(); } }; class SquareWaveFactory final : public WaveFactory { public: std::unique_ptrWaveGenerator CreateWave() const override { return std::make_uniqueSquareWaveGenerator(); } };到這一步我估計有經驗的開發(fā)者已經發(fā)現(xiàn)了這個“工廠”和常見的“把type字符串丟進去返回對應對象”的那種寫法不太一樣。它沒有if分支甚至沒有一個集中式的分發(fā)邏輯。是的這就是工廠方法模式和簡單工廠的核心差別返回什么東西這件事被下放到了子類里而不是保留在一個集中函數(shù)里。3.2 調用方式與動態(tài)類型識別的小技巧調用方式倒是很簡單int main() { SineWaveFactory sineFactory; sineFactory.GenerateAndPrint(16); SquareWaveFactory squareFactory; squareFactory.GenerateAndPrint(16); }這個輸出會展示正弦波和方波各自的采樣數(shù)據(jù)。很多初學C的同學會糾結一個問題CreateWave返回的是unique_ptrWaveGenerator那我怎么知道它底層到底是一個正弦波還是方波這個問題得分兩說。如果產品接口設計得足夠完善調用方壓根不需要關心具體類型只需要對著基類接口操作。如果你真的有必要知道具體類型——比如要下發(fā)給不同處理鏈路的模塊——那么應當走到工廠方法之外去思考設計問題產品的職責邊界是不是沒劃分干凈是否所有波形生成器都真的適合跑在同一個抽象下這種情況通常意味著接口里缺少一個能區(qū)分行為差異的虛函數(shù)。還有一個細節(jié)在工廠方法里返回unique_ptr和返回shared_ptr其實是兩種不同的語義選擇。前者表示創(chuàng)建者并不共享對象所有權誰調用誰獨占后者表示這個產物可能被多個持有者同時引用。實際項目里如果產品的生命周期和調用方深度綁定unique_ptr更合適因為可以避免無謂的引用計數(shù)開銷如果產品將來會被多個模塊共享shared_ptr才是合理選擇。3.3 關鍵“為什么”公共流程代碼如何復用現(xiàn)在再回頭看WaveFactory::GenerateAndPrint你會發(fā)現(xiàn)它其實是個模版方法Template Method的影子。工廠方法模式通常和模版方法配合使用——基類定義完整流程把其中一個步驟創(chuàng)建產品延遲到子類實現(xiàn)。這樣每個子類雖然工廠方法內容不同但上層流程完全一致。很多人忽略了這個配合關系只盯著工廠方法本身導致寫出來的代碼仍然是“每個子類重復一套公共流程”。而 C 里復用公共流程最自然的方式就是把這個流程放在基類非虛函數(shù)中需要變化的那一步調用純虛函數(shù)。這個組合設計能讓代碼的復用程度顯著提升也是我想強調的一個比較實用的技巧。4. 怎么比“C默認行為”多做一步返回類型拷貝問題的避坑手冊這部分是C里最容易把人繞暈的地方我單獨拿出來展開說。因為工廠方法涉及返回一個對象而這個對象需要穿過函數(shù)返回值這道“邊界”。4.1 為什么基類返回類型不能直接返回具體對象如果直接寫WaveGenerator CreateWave() const; // 錯那你的產品對象在返回的瞬間就會被切片slicing。所謂切片就是子類對象按基類類型的值返回時編譯器會構造一個WaveGenerator臨時對象而子類部分的數(shù)據(jù)被丟棄。這在靜態(tài)類型語言里是很容易犯的低級錯誤尤其對于從Java轉C的開發(fā)者來說因為Java里一切引用本質上都是指針語義不會有這種問題。C的正確做法前面已經寫過了返回指針或引用。引用返回有個生命周期風險工廠方法一般返回本地的局部對象如果返回引用就會變成一個懸空引用。所以現(xiàn)代C里最安全的默認選擇就是返回unique_ptr或者shared_ptr。4.2 基類必須聲明虛析構函數(shù)原因和解決辦法這個其實是老生常談但它在工廠方法里有個特別致命的場景值得單獨強調。想想看你從工廠方法里拿到了一個unique_ptrWaveGenerator底層實際是SineWaveGenerator。在銷毀這個對象時unique_ptrWaveGenerator的析構函數(shù)會調用WaveGenerator的析構函數(shù)。如果WaveGenerator的析構函數(shù)不是虛函數(shù)那它就不會再去調用SineWaveGenerator的析構函數(shù)于是子類里持有的資源可能不會被釋放。在波形生成器這種簡單場景里可能問題不大但如果子類持有文件句柄、網絡連接或者自己分配的大塊緩沖這個問題就立刻變成內存泄漏。解決辦法也很簡單在產品基類的析構函數(shù)前面加個virtualvirtual ~WaveGenerator() default;一定要記住沒有虛析構函數(shù)的基類就不能被作為工廠方法的返回類型來用。這不是風格問題是安全底線。4.3 構造函數(shù)里調用工廠方法C虛調用的致命坑這里插一個我在真實代碼評審里見過的經典錯誤。有一位同事在一個模擬器框架里把工廠方法的調用放在基類的構造函數(shù)里期望在構造基類時就能動態(tài)創(chuàng)建出具體的產品。結果程序運行后產品永遠是一個“空殼”類型的實例。這個問題的根因在C的構造順序里在基類構造函數(shù)執(zhí)行期間虛函數(shù)表指向的仍然是基類的虛函數(shù)版本。也就是說C的虛函數(shù)多態(tài)機制在構造期間還沒有完全生效。你在構造函數(shù)里調用CreateWave()即使它被聲明為虛函數(shù)當前調用的仍然只會是WaveFactory::CreateWave()—— 而基類里那個純虛函數(shù)根本沒法被調用能編譯運行純粹是因為某些寫法兜住了但行為完全不對。正確做法是不要在構造函數(shù)里調用虛函數(shù)。把創(chuàng)建動作移動到獨立的方法里讓它在對象完全構造成功后再被觸發(fā)。這也是工廠方法存在于“創(chuàng)建對象”這個語境下的一個側面提醒——它適合在產品對象已經被完整構造之后對某個接口發(fā)起“生產”請求而不是在構造過程中自找麻煩。5. 三種容易混淆的工廠形態(tài)簡單工廠、工廠方法、抽象工廠的實際選擇很多人把“工廠”這個詞當作一個萬能藥遇到創(chuàng)建邏輯有點復雜就往工廠里套。其實光C社區(qū)里就至少流傳著三種不一樣工廠形態(tài)把它們區(qū)分清楚在做設計決策時會有幫助。5.1 三個形態(tài)的本質對比先看簡單工廠它的特征是有一個集中的CreateXxx靜態(tài)函數(shù)接收一個參數(shù)然后根據(jù)參數(shù)開關分發(fā)到不同的具體構造函數(shù)。這個不算GOF里的經典模式而是一種編碼慣例但它最常見幾乎所有做C的人都會先寫這個。再看工廠方法就是前面一直在講的它把創(chuàng)建動作定義在基類里具體生產交給子類。最后是抽象工廠它不是一兩個類而是一整套產品族創(chuàng)建接口。比如圖形界面庫里你有一個“Windows風格工廠”能同時創(chuàng)建按鈕、文本框、滾動條還有一個“Linux風格工廠”也創(chuàng)建同簽名的三個控件只是每個控件的實現(xiàn)完全不同。這里的核心是產品族之間的配套一致性。它們三者的關系我習慣用一個表格來總結形態(tài)創(chuàng)建入口核心特點適用場景簡單工廠集中式靜態(tài)函數(shù)靠條件分支創(chuàng)建產品擴展需改原函數(shù)產品類型少、變化不頻繁的小項目工廠方法基類虛函數(shù)子類實現(xiàn)每個子類決定自己的產品符合封閉/開放原則產品種類會持續(xù)擴展創(chuàng)建流程相對統(tǒng)一抽象工廠一組創(chuàng)建接口按產品族實現(xiàn)保證產品族內部一致性復雜度和靈活度都高多套風格/系列的產品同時存在啟動時選一整套5.2 實際項目里如何選擇別為設計而設計我的經驗是不要一上來就抽象工廠大部分項目用到工廠方法就夠了。如果一個系統(tǒng)只需要支持兩三種固定的產品類型簡單工廠反而更直接——你不需要建立那么多繼承關系也不需要一個虛函數(shù)表跳來跳去。但一旦你預見到“產品類型每周都可能增加一類”而且每一類的創(chuàng)建方式都有其特殊性那簡單工廠的分支就會開始膨脹。這時切換到工廠方法新增類型只需要新增一個產品類和對應的工廠子類老代碼一行不動。另外的一個參考指標是看創(chuàng)建流程的骨架是否穩(wěn)定。如果創(chuàng)建一個對象總是要經過“解析配置—構造內部組件—綁定外部依賴—注冊回調”這幾步而具體每一步各家不同那么工廠方法配合模版方法結構就非常合適。如果連流程骨架本身都不穩(wěn)定每個產品類型的生命周期和管理方式都大相徑庭那再用工廠硬套只會讓代碼更擰巴——這時候可以直接在更高層級用一個注冊表 委托函數(shù)的路子了。6. C工程里的實際擴展注冊表工廠和lambda工廠傳統(tǒng)工廠方法模式是依賴繼承來解決問題的但在現(xiàn)代C里工程上還有兩種很常見的變體注冊表工廠和lambda工廠。它們不是設計模式的新概念而是利用語言特性對工廠方法模式的適配。6.1 注冊表工廠用映射表替代一大堆子類如果你有幾十種產品為每一個產品都寫一個工廠子類會顯得特別冗余。這時用一個注冊表把字符串和std::function映射起來能讓代碼干凈得多#include functional #include unordered_map class WaveRegistry { public: using FactoryFn std::functionstd::unique_ptrWaveGenerator(); void Register(const std::string name, FactoryFn fn) { factories_[name] std::move(fn); } std::unique_ptrWaveGenerator Create(const std::string name) const { auto it factories_.find(name); if (it factories_.end()) { return nullptr; } return it-second(); } private: std::unordered_mapstd::string, FactoryFn factories_; };然后你就可以在某個模塊初始化時把具體創(chuàng)建函數(shù)注冊進去WaveRegistry registry; registry.Register(sine, []() - std::unique_ptrWaveGenerator { return std::make_uniqueSineWaveGenerator(); }); registry.Register(square, []() - std::unique_ptrWaveGenerator { return std::make_uniqueSquareWaveGenerator(); });調用側只需要知道名稱完全不接觸任何具體工廠類。這種方式對插件化、動態(tài)加載特別友好因為每個插件只需要把自己支持的類型注冊進去就行不需要改主程序里的任何分發(fā)邏輯。在實際工程里這是我在處理“產品類型非常多”時最常用的方式。6.2 lambda工廠的簡潔邊界還有一種更輕量的用法就是干脆不建工廠類直接在需要創(chuàng)建產品的地方用lambda寫一個創(chuàng)建函數(shù)。這個方式適合那種“只在一個地方創(chuàng)建、其他地方不關心”的場景——比如某個服務內部構建自己的依賴組件時直接寫個lambda作為默認工廠即可。lambda工廠的邊界在于它不適合“工廠本身需要復用”的場景也不適合產品創(chuàng)建流程較長、需要子類共享骨架的場景。如果創(chuàng)建邏輯只有兩三行而且不會在第二處復用我支持你用lambda一旦創(chuàng)建過程超過十行或者你發(fā)現(xiàn)這個lambda要在三個以上地方被調用那就該冷靜下來把它升格為真正的類或注冊表條目。7. 現(xiàn)代C語境下的工廠方法演進智能指針與移動語義的配合C已經從裸指針時代走過來了工廠方法模式也搭上了新特性的快車。最明顯的變化是返回值的所有權語義被大大強化。7.1 從裸指針到unique_ptr/shared_ptr的變遷老式的C工廠方法通常返回一個裸指針注釋里寫著“調用者負責delete”。這套約定在現(xiàn)代C里已經基本被淘汰原因很簡單所有權不明確容易漏刪也難以表達是獨占還是共享?，F(xiàn)在的主流寫法是以std::unique_ptr或std::shared_ptr作為返回類型。unique_ptr表示明確的獨占所有權移動語義讓返回值在函數(shù)間傳遞幾乎零開銷shared_ptr則適用于產品會被多個模塊共享的場景。一個小貼士在C14/17里如果產品類型繼承自enable_shared_from_this那么建議直接用shared_ptr作為工廠返回類型否則后續(xù)再轉成shared_ptr時容易遇到所有權割裂的問題。7.2 移動語義和完美轉發(fā)對工廠方法的影響移動語義讓工廠方法里構造產品對象的開銷進一步下降。比如產品內部持有很大的緩沖區(qū)C11之前可能需要拷貝整個緩沖區(qū)現(xiàn)在直接移動即可std::unique_ptrBufferGenerator CreateBufferGenerator(std::vectordouble data) { auto gen std::make_uniqueBufferGenerator(); gen-SetData(std::move(data)); // 不再拷貝 return gen; }完美轉發(fā)則讓工廠方法可以接受任意參數(shù)并原樣轉發(fā)給構造函數(shù)。這在有些復雜產品初始化時很方便template typename... Args std::unique_ptrWaveGenerator CreateWrapped(Args... args) { return std::make_uniqueSineWaveGenerator(std::forwardArgs(args)...); }但要留意一下編譯器的模板理解和報錯信息C模板報錯自古就繞。對這種代碼重要建議是給工廠方法加上概念約束(concepts)或至少在注釋里寫清楚參數(shù)含義否則三個月后你自己都會忘記這些Args該怎么傳。7.3 C20/23的新工具讓工廠方法更健壯在C20和C23里我比較關注兩個特性在工廠方法上的應用。一個是concepts可以用它來約束產品類型必須繼承自WaveGenerator在編譯期就攔截不匹配的類型template DerivedFromWaveGenerator T std::unique_ptrWaveGenerator CreateAsWave() { return std::make_uniqueT(); }另一個是std::expected或std::optional它們讓工廠方法的“創(chuàng)建失敗”語義更清晰。比如注冊表工廠里找不到對應類型時以前返回nullptr調用方還得判空現(xiàn)在可以把錯誤原因一道返回。雖然會增加一點模板復雜度但對大型項目頗有幫助。8. 測試與調試心得工廠方法在實踐里的隱藏價值最后這部分說說工廠方法給測試和調試帶來的便利以及在真實項目中它的另一個“隱形好處”。8.1 便于單元測試的依賴注入點如果你的所有模擬對象都通過工廠方法創(chuàng)建那么在測試時你可以輕易地替換掉整個產品子樹。比如你要測GenerateAndPrint這個公共流程不需要真的創(chuàng)建正弦波只要用一個測試專用的假工廠讓它返回一個記錄型的假產品就足夠了。生產代碼和測試代碼之間通過工廠接口對接耦合度控制得很好。這也解釋了為什么很多優(yōu)秀的C測試框架里mock對象幾乎都依賴工廠或抽象接口——因為只有基于接口編程才能在運行時替換依賴。8.2 一個調試排錯的具體案例詭異的產品類型錯亂有一次我在調試一套渲染引擎發(fā)現(xiàn)場景中的某個物體偶爾會表現(xiàn)出完全不屬于自己類型的渲染行為。排查了很久最后定位到是工廠方法里返回了錯誤的類型轉換。當時的代碼類似于return std::make_sharedSomeDerived(...);但由于基類的工廠方法簽名是返回基類類型而子類的工廠方法里寫了一塊不正確的類型轉換邏輯導致運行時拿到的是一個類型不匹配的實例。這類問題如果不用工廠模式而直接在各調用方創(chuàng)建對象往往會被埋得更深。工廠方法把“創(chuàng)建”這一層面統(tǒng)一收口后定位起來反而容易很多。8.3 工廠方法模式給你帶來的全局視角我自己覺得工廠方法模式真正的價值在于它強迫你把“創(chuàng)建”這件事當成一個完整的、可擴展的關卡。每一個產品不再是散落在系統(tǒng)各處的new或者make_unique而是有明確入口、有明確職責、有明確測試點的組件。這會讓整個系統(tǒng)的結構邊界清晰起來——無論你是自己維護一個中等規(guī)模的項目還是在團隊里協(xié)作這種邊界感對降低維護成本的作用遠超模式本身。9. 最后再分享一個經驗從簡單工廠到工廠方法的平滑重構路徑如果你現(xiàn)在的代碼還是一個簡單的集中式CreateByType函數(shù)別急著推倒重來平滑重構路徑很關鍵。第一步先把創(chuàng)建入口修正為返回std::unique_ptrWaveGenerator而不是裸指針——這是所有權語義的明確化。第二步把函數(shù)改造成基類的虛函數(shù)讓每個分支對應一個子類。這一步不需要一次做完可以先讓最常用的幾個類型走子類路線其他類型仍保留在基類里做兜底。第三步逐步把“按類型分發(fā)”的邏輯從調用方中移除讓所有調用方只看基類接口不再關心具體類型。最后再考慮是否引入注冊表或lambda工廠判斷標準是子類數(shù)量是否多到了寫起來很累的程度。這樣重構的好處是每一步都是可編譯、可測試的不會出現(xiàn)推倒重來的大跨度失敗。我一直覺得設計模式不是拿來炫耀詞匯量的而是拿來讓明天的自己少掉點頭發(fā)的。如果你手頭正有一個分支發(fā)散得很難受的創(chuàng)建邏輯不妨試試這個路徑。寫完最后一行你多半會跟我一樣覺得那點重構的功夫真值。