裝飾器模式在C里被聊得很多但真正能從上手到落地、把設(shè)計(jì)意圖講透的文章其實(shí)并不多。剛工作那陣子我看《Head First 設(shè)計(jì)模式》Java寫得很爽等回到C項(xiàng)目里自己上手才發(fā)現(xiàn)有一堆坑等著踩對象切片、虛析構(gòu)、所有權(quán)轉(zhuǎn)移、和STL的配合還有性能上那些看似不起眼的開銷。折騰過幾輪之后才慢慢摸出一套適合自己的打法。這篇文章我不打算講教科書式的定義也不會貼一堆只有類名沒有業(yè)務(wù)場景的抽象代碼。我會從實(shí)際項(xiàng)目中最常見的需求切入比如給已有的接口加日志、加計(jì)時(shí)、加權(quán)限校驗(yàn)把裝飾器模式從基礎(chǔ)實(shí)現(xiàn)到C特色改進(jìn)講一遍附帶踩過的坑和排查思路。適合那些設(shè)計(jì)模式看過但沒真用明白的C程序員也適合準(zhǔn)備重構(gòu)手頭模塊、想在不改老代碼的前提下擴(kuò)展功能的人。1. 裝飾器模式要解決的真實(shí)問題1.1 先從“子類爆炸”說起想象你有一條消息發(fā)送鏈路基礎(chǔ)發(fā)送可能只是把文本寫進(jìn)日志文件后來產(chǎn)品說需要加密運(yùn)維說要壓縮測試說要統(tǒng)計(jì)耗時(shí)老板說敏感信息要脫敏……如果每加一個(gè)功能就繼承一次類數(shù)量直接起飛。我見過最夸張的一個(gè)項(xiàng)目一個(gè)FileSender派生出了十幾個(gè)子類EncryptedFileSender、CompressedEncryptedFileSender、TimedCompressedEncryptedFileSender……光看名字就知道維護(hù)有多酸爽更別提組合順序一變又要新增一個(gè)類。子類爆炸的真正根源是功能擴(kuò)展點(diǎn)被硬編碼成了類型層級而實(shí)際需求往往是一組正交的橫切關(guān)注點(diǎn)日志、鑒權(quán)、統(tǒng)計(jì)、緩存疊加在同一個(gè)核心邏輯上。裝飾器模式給出的答案是把這些橫切關(guān)注點(diǎn)做成一層一層的“外包裝”每層實(shí)現(xiàn)同一個(gè)接口內(nèi)部再調(diào)用下一個(gè)對象。核心業(yè)務(wù)類不用改新功能就是新增一個(gè)裝飾器類組合順序由運(yùn)行時(shí)構(gòu)造決定。1.2 C 語境下的特殊考量Java里裝飾器模式幾乎是純面向?qū)ο蟮臉?biāo)準(zhǔn)作業(yè)接口 多個(gè)實(shí)現(xiàn)類 組合。但C有自己的一套脾氣直接搬到C會出問題對象切片如果接口用基類傳參而裝飾器持有基類對象賦錯(cuò)一次值就把派生部分切沒了。所有權(quán)語義裝飾器包著被裝飾對象到底誰刪誰裸指針時(shí)代這是懸垂指針和多刪的溫床。虛析構(gòu)缺失接口基類沒有虛析構(gòu)delete的時(shí)候只析構(gòu)了基類部分資源泄漏沒跑。性能敏感虛函數(shù)調(diào)用有間接跳轉(zhuǎn)一次兩次無所謂在熱路徑里疊五六個(gè)裝飾器就能看到性能差異。所以C里實(shí)現(xiàn)裝飾器不只是套用UML類圖關(guān)鍵是把值語義、移動語義、智能指針、甚至模板元編程揉進(jìn)去才能寫出既符合模式思想又不別扭的代碼。2. 經(jīng)典Gof風(fēng)格實(shí)現(xiàn)先把基礎(chǔ)打牢2.1 角色拆分與接口設(shè)計(jì)經(jīng)典實(shí)現(xiàn)里有四個(gè)角色Component抽象組件定義業(yè)務(wù)接口裝飾器和被裝飾對象都實(shí)現(xiàn)它。ConcreteComponent具體組件真正干活的類。Decorator裝飾器基類持有Component的引用/指針轉(zhuǎn)發(fā)所有接口調(diào)用。ConcreteDecorator具體裝飾器在轉(zhuǎn)發(fā)前后加自己的邏輯。在實(shí)際項(xiàng)目里接口要設(shè)計(jì)得“恰好夠用”。如果一個(gè)接口塞了幾十個(gè)方法裝飾器基類就得轉(zhuǎn)發(fā)幾十次寫起來很煩。我曾經(jīng)封裝過一個(gè)Stream接口里面讀寫定位刷新全都有每個(gè)裝飾器都有一大堆透傳代碼后來學(xué)聰明了接口拆分把讀寫核心抽成單獨(dú)的Readable和Writable裝飾器只轉(zhuǎn)發(fā)自己關(guān)心的部分。2.2 一個(gè)能跑起來的示例下面我用一個(gè)文本處理鏈來演示TextProcessor基類核心實(shí)現(xiàn)是PlainTextProcessor裝飾器分別是去空白、轉(zhuǎn)大寫。實(shí)際項(xiàng)目里這個(gè)思路完全可以套到網(wǎng)絡(luò)包處理、圖像濾波、價(jià)格計(jì)算等場景。#include iostream #include string #include memory #include algorithm // 抽象組件 class TextProcessor { public: virtual ~TextProcessor() default; virtual std::string process(const std::string input) 0; }; // 具體組件 class PlainTextProcessor : public TextProcessor { public: std::string process(const std::string input) override { return input; } }; // 裝飾器基類 class TextDecorator : public TextProcessor { protected: std::unique_ptrTextProcessor inner_; public: explicit TextDecorator(std::unique_ptrTextProcessor inner) : inner_(std::move(inner)) {} }; // 具體裝飾器A轉(zhuǎn)大寫 class UpperCaseDecorator : public TextDecorator { public: using TextDecorator::TextDecorator; std::string process(const std::string input) override { std::string result inner_-process(input); std::transform(result.begin(), result.end(), result.begin(), [](unsigned char c) { return std::toupper(c); }); return result; } }; // 具體裝飾器B去除連續(xù)空格 class CompactWhitespaceDecorator : public TextDecorator { public: using TextDecorator::TextDecorator; std::string process(const std::string input) override { std::string result inner_-process(input); std::string output; bool inWhitespace false; for (char c : result) { if (std::isspace(static_castunsigned char(c))) { if (!inWhitespace) output.push_back( ); inWhitespace true; } else { output.push_back(c); inWhitespace false; } } return output; } };使用方式就是在構(gòu)造時(shí)層層包裹int main() { auto processor std::make_uniqueUpperCaseDecorator( std::make_uniqueCompactWhitespaceDecorator( std::make_uniquePlainTextProcessor())); std::string text hello world from decorator ; std::cout processor-process(text) std::endl; return 0; }注意這里TextDecorator構(gòu)造函數(shù)接收的是unique_ptrUpperCaseDecorator用using TextDecorator::TextDecorator繼承構(gòu)造函數(shù)省掉了自己寫一遍轉(zhuǎn)發(fā)的代碼。2.3 構(gòu)造函數(shù)簽名設(shè)計(jì)的教訓(xùn)有一個(gè)細(xì)節(jié)值得單獨(dú)說裝飾器的構(gòu)造參數(shù)我強(qiáng)烈建議用unique_ptr而不要用裸指針。用裸指針的話調(diào)用方很容易寫出這樣的代碼auto inner new PlainTextProcessor(); auto deco new UpperCaseDecorator(inner); delete deco; // inner 誰來刪業(yè)務(wù)代碼里一旦漏了delete inner就是內(nèi)存泄漏刪兩次就是未定義行為。用unique_ptr把所有權(quán)在構(gòu)造時(shí)直接轉(zhuǎn)移干凈裝飾器析構(gòu)時(shí)自然會把內(nèi)部對象析構(gòu)掉生命周期清晰。傳引用也試過但會有個(gè)問題被裝飾對象必須活得比裝飾器久在工廠函數(shù)里組合對象時(shí)臨時(shí)對象生命周期很容錯(cuò)。最后實(shí)用下來的方案就是所有權(quán)跟著裝飾器走全部用unique_ptr串成一條鏈。提示如果你需要多個(gè)裝飾器共享同一個(gè)被裝飾對象比如做觀察者模式配合那unique_ptr不合適改成shared_ptr并注意循環(huán)引用。我在實(shí)現(xiàn)一個(gè)簡單的發(fā)布訂閱裝飾器時(shí)裝飾器要同時(shí)包裝多個(gè)訂閱者就用shared_ptr容器來持有它們。3. C 特色改進(jìn)棧上裝飾器與函數(shù)式包裝3.1 棧上裝飾器避免堆分配經(jīng)典方式里每個(gè)裝飾器都是一次堆分配。對于延遲不敏感的中后臺代碼沒問題但游戲里的技能Buff系統(tǒng)、實(shí)時(shí)渲染管線里的后處理鏈堆分配太頻繁會帶來性能抖動。C特有的優(yōu)雅解法是模板加變參構(gòu)造在棧上完成裝飾器嵌套template typename Component, typename... Decorators class DecoratedProcessor; // 遞歸模板展開逐層包裹 template typename Component class DecoratedProcessorComponent { public: std::string process(const std::string input) { return component_.process(input); } private: Component component_; }; template typename Component, typename Decorator, typename... Rest class DecoratedProcessorComponent, Decorator, Rest... : public Decorator { public: template typename... Args explicit DecoratedProcessor(Args... args) : Decorator(std::forwardArgs(args)...) {} };這個(gè)寫法有點(diǎn)燒腦但核心思想是用編譯期遞歸把裝飾器展開成繼承鏈所有對象都分配在棧上沒有虛函數(shù)調(diào)用、沒有堆空分配、沒有運(yùn)行時(shí)多態(tài)開銷。缺點(diǎn)也明顯裝飾器類型必須編譯期確定運(yùn)行時(shí)動態(tài)組合做不到。什么時(shí)候用棧上版本裝飾器集合固定的場景比如一個(gè)產(chǎn)品線的固定消息處理鏈?zhǔn)裁磿r(shí)候用經(jīng)典版本裝飾器需要配置驅(qū)動、運(yùn)行時(shí)決定的場景比如根據(jù)配置中心動態(tài)啟停某個(gè)中間件。我通常把兩者配合核心鏈用模板固定可熱插拔的擴(kuò)展用虛函數(shù)版本。3.2 用 std::function 簡化裝飾器如果裝飾器邏輯非常簡單加個(gè)日志、加個(gè)耗時(shí)統(tǒng)計(jì)不值得定義一整套類。利用C的std::function可以把裝飾器退化成一個(gè)函數(shù)包裝鏈。#include functional #include string #include chrono #include iostream using ProcessFunc std::functionstd::string(const std::string); ProcessFunc withLogging(ProcessFunc next) { return [next](const std::string input) { std::cout [log] before process, input size input.size() std::endl; std::string result next(input); std::cout [log] after process, result size result.size() std::endl; return result; }; } ProcessFunc withTiming(ProcessFunc next) { return [next](const std::string input) { auto start std::chrono::steady_clock::now(); std::string result next(input); auto end std::chrono::steady_clock::now(); std::cout [timer] std::chrono::durationdouble, std::milli(end - start).count() ms std::endl; return result; }; } int main() { ProcessFunc core [](const std::string input) { return input; }; ProcessFunc pipeline withLogging(withTiming(core)); pipeline(hello); return 0; }輸出會看到先打日志、再計(jì)時(shí)實(shí)際上執(zhí)行順序是withLogging 包著 withTiming所以流程是進(jìn)入withLogging lambda打印before日志調(diào)用withTiming進(jìn)入withTiming lambda計(jì)時(shí)開始調(diào)用core計(jì)時(shí)結(jié)束返回給withLogging打印after日志。用std::function最大的好處是靈活性構(gòu)建管道時(shí)可以按配置拼接任意一個(gè)環(huán)節(jié)都可以替換成函數(shù)或lamba。缺點(diǎn)也很現(xiàn)實(shí)std::function本身的調(diào)用開銷比直接虛函數(shù)還要高一點(diǎn)我壓測過簡單的轉(zhuǎn)發(fā)鏈每層std::function大概多幾十納秒。非極端熱路徑完全可接受但如果你每次請求要走幾十層裝飾器、每秒百萬請求就得回到模板方案或者手寫虛函數(shù)。3.3 C17 之后把裝飾器做成可變參數(shù)模板鏈還有一種介于兩者之間的思路利用C17的折疊表達(dá)式把裝飾器直接拼成一條鏈代碼寫起來挺像函數(shù)式編程里的middleware。#include iostream #include string template typename Fn auto decorate(Fn fn) { return fn; } template typename Dec, typename... Rest auto decorate(Dec dec, Rest... rest) { return dec(decorate(rest...)); } int main() { auto core [](const std::string s) { return s; }; auto withPrefix [](auto next) { return [next](const std::string s) { return [prefix] next(s); }; }; auto withSuffix [](auto next) { return [next](const std::string s) { return next(s) [suffix]; }; }; auto pipeline decorate(withPrefix, withSuffix, core); std::cout pipeline(hello) std::endl; return 0; }這種方式比std::function更輕量類型可以在編譯期完整推導(dǎo)但調(diào)試信息非常反人類——一旦IDE里報(bào)錯(cuò)模板層數(shù)深到你懷疑人生。我個(gè)人的建議裝飾器數(shù)量不超過三個(gè)、邏輯簡單的時(shí)候模板玩一玩沒問題大型工程里還是看清楚點(diǎn)好可維護(hù)性優(yōu)先。4. 實(shí)戰(zhàn)案例從需求到組合完整走一遍4.1 場景設(shè)定一個(gè)可擴(kuò)展的HTTP請求處理模塊假設(shè)我們有一個(gè)老項(xiàng)目中央處理函數(shù)是個(gè)幾百行的spaghettivoid handleRequest(HttpRequest req, HttpResponse resp);每次上線新需求就在這個(gè)函數(shù)里加一個(gè)if語句加一個(gè)邏輯分支改了半年之后誰也動不了?，F(xiàn)在回頭用裝飾器重構(gòu)第一步定義處理接口struct HttpHandler { virtual ~HttpHandler() default; virtual void handle(HttpRequest req, HttpResponse resp) 0; };然后核心處理器實(shí)現(xiàn)class CoreHttpHandler : public HttpHandler { public: void handle(HttpRequest req, HttpResponse resp) override { // 真正的業(yè)務(wù)邏輯 resp.setBody(Hello from core handler); } };4.2 日志裝飾器日志裝飾器的關(guān)注點(diǎn)是記錄請求路徑、狀態(tài)碼、耗時(shí)。不打進(jìn)業(yè)務(wù)代碼里單獨(dú)一層class LoggingHandler : public HttpHandler { std::unique_ptrHttpHandler inner_; public: explicit LoggingHandler(std::unique_ptrHttpHandler inner) : inner_(std::move(inner)) {} void handle(HttpRequest req, HttpResponse resp) override { auto start std::chrono::steady_clock::now(); inner_-handle(req, resp); auto end std::chrono::steady_clock::now(); std::cout [log] path req.path() status resp.status() cost std::chrono::duration_caststd::chrono::milliseconds(end - start).count() ms std::endl; } };4.3 權(quán)限校驗(yàn)裝飾器權(quán)限校驗(yàn)的核心邏輯是沒權(quán)限直接短路不再調(diào)內(nèi)部處理器。這種“短路”行為正好體現(xiàn)了裝飾器的職責(zé)分離優(yōu)勢——CoreHttpHandler完全不知道權(quán)限什么東西class AuthHandler : public HttpHandler { std::unique_ptrHttpHandler inner_; public: explicit AuthHandler(std::unique_ptrHttpHandler inner) : inner_(std::move(inner)) {} void handle(HttpRequest req, HttpResponse resp) override { if (!req.hasValidToken()) { resp.setStatus(401); resp.setBody(Unauthorized); return; // 短路不再調(diào)用內(nèi)部處理器 } inner_-handle(req, resp); } };4.4 緩存裝飾器緩存裝飾器的思路是如果命中直接返回不穿透到內(nèi)部。這里要特別注意“短路緩存”兩個(gè)裝飾器同時(shí)存在時(shí)的順序。class CachedHandler : public HttpHandler { std::unique_ptrHttpHandler inner_; std::unordered_mapstd::string, std::string cache_; public: explicit CachedHandler(std::unique_ptrHttpHandler inner) : inner_(std::move(inner)) {} void handle(HttpRequest req, HttpResponse resp) override { auto key req.path() req.queryString(); auto it cache_.find(key); if (it ! cache_.end()) { resp.setBody(it-second); return; } inner_-handle(req, resp); if (resp.status() 200) { cache_[key] resp.body(); } } };4.5 組合順序決定行為組合順序的一個(gè)經(jīng)典案例auto handler std::make_uniqueLoggingHandler( std::make_uniqueAuthHandler( std::make_uniqueCachedHandler( std::make_uniqueCoreHttpHandler())));這個(gè)是外層日志、中層鑒權(quán)、內(nèi)層緩存。行為是請求進(jìn)來先記日志然后鑒權(quán)鑒權(quán)通過后查緩存緩存沒有再進(jìn)核心。但如果你把Auth和Cache換位置auto handler2 std::make_uniqueLoggingHandler( std::make_uniqueCachedHandler( std::make_uniqueAuthHandler( std::make_uniqueCoreHttpHandler())));行為就變成請求進(jìn)來先記日志直接查緩存如果緩存命中就完全不鑒權(quán)這在安全敏感系統(tǒng)里是事故。我說這個(gè)例子是想強(qiáng)調(diào)裝飾器的順序不是隨便定的必須由業(yè)務(wù)語義決定最好在文檔里畫清楚調(diào)用順序圖別只留一份代碼。4.6 從配置工廠動態(tài)組裝裝飾器在線系統(tǒng)里裝飾器鏈經(jīng)常要按配置調(diào)整。可以用簡單工廠std::unique_ptrHttpHandler buildHandler(const Config cfg) { std::unique_ptrHttpHandler handler std::make_uniqueCoreHttpHandler(); if (cfg.enableCache) { handler std::make_uniqueCachedHandler(std::move(handler)); } if (cfg.enableAuth) { handler std::make_uniqueAuthHandler(std::move(handler)); } if (cfg.enableLog) { handler std::make_uniqueLoggingHandler(std::move(handler)); } return handler; }這里要小心賦值給新的unique_ptr時(shí)舊的handler對象所有權(quán)被轉(zhuǎn)移進(jìn)了新裝飾器再訪問舊handler就是懸空。我在這個(gè)工廠里實(shí)際踩過一次在cfg.enableCache分支里取handler.get()存了個(gè)全局指針后面繼續(xù)用結(jié)果對象已經(jīng)沒了排查了好幾個(gè)小時(shí)。關(guān)鍵原則在組合鏈構(gòu)造期間不要保存任何對中間對象的裸指針等整個(gè)鏈構(gòu)造完再取get()。5. 與相關(guān)模式的對比與選型5.1 裝飾器 vs 繼承擴(kuò)展能力完全不同對比一下兩種方式在增加“加解密”功能時(shí)的差異。繼承方式定義EncryptedFileHandler繼承FileHandler重寫寫方法。如果要“加密壓縮”呢定義EncryptedCompressedFileHandler繼承誰如果還要“加密限流”類數(shù)量繼續(xù)膨脹。裝飾器方式每個(gè)能力一個(gè)類自由組合需要什么包什么不需要時(shí)直接不包。核心邏輯和橫切關(guān)注點(diǎn)徹底解耦。5.2 裝飾器 vs 代理模式控制權(quán)歸屬不同代理模式Proxy和裝飾器結(jié)構(gòu)很像經(jīng)常有人混淆。我的理解代理強(qiáng)調(diào)的是“控制訪問”它創(chuàng)建和持有真實(shí)對象的引用在調(diào)用前后加入訪問控制、延遲加載、遠(yuǎn)程通信這些管理性邏輯調(diào)用方感知到的是一個(gè)代理甚至可能未被創(chuàng)建。裝飾器強(qiáng)調(diào)的是“增強(qiáng)功能”它在已有對象上疊加新行為而且可以遞歸疊加重點(diǎn)在于擴(kuò)展。舉例一個(gè)ImageProxy用于延遲加載大圖這是代理一個(gè)WatermarkDecorator在圖片上加水印這是裝飾器。代理控制你什么時(shí)候能看到圖裝飾器改變你看到的圖本身。5.3 裝飾器 vs 策略模式業(yè)務(wù)邏輯的變換維度策略模式解決的是“同一動作的不同算法”比如排序算法的選擇、壓縮格式的選擇在構(gòu)造時(shí)注入其中一個(gè)策略。裝飾器解決的是“