簡(jiǎn)介由王桂林整理的設(shè)計(jì)模式學(xué)習(xí)筆記PDF是一份面向軟件開(kāi)發(fā)者、架構(gòu)師與中高級(jí)編程學(xué)習(xí)者的系統(tǒng)性參考資料旨在幫助讀者理解并運(yùn)用經(jīng)典設(shè)計(jì)模式提升代碼可維護(hù)性與擴(kuò)展性。文檔以GOF著作《Design Patterns》為線索從歷史淵源講起完整覆蓋模式名稱、問(wèn)題、解決方案、效果等陳述要素并針對(duì)單一職責(zé)、開(kāi)閉、依賴倒置、接口隔離等核心設(shè)計(jì)原則展開(kāi)剖析配有代碼示范、學(xué)習(xí)建議與推薦書(shū)目幫助讀者既理解概念又能落地實(shí)踐。資源為單份PDF電子文檔大小約3.09MB內(nèi)部按章節(jié)目錄組織層次分明可通讀學(xué)習(xí)也可按需檢索特定原則或模式。已有157人學(xué)習(xí)適合自學(xué)、復(fù)習(xí)或在團(tuán)隊(duì)內(nèi)部作為設(shè)計(jì)模式培訓(xùn)材料能幫助讀者快速建立起完整的設(shè)計(jì)模式知識(shí)框架并減少開(kāi)發(fā)中重復(fù)踩坑。1. 設(shè)計(jì)模式面試八股還是重構(gòu)后悔藥設(shè)計(jì)模式在項(xiàng)目里從來(lái)不是加分題而是欠債題——早期沒(méi)選對(duì)結(jié)構(gòu)后期需求一變更改一個(gè)功能要牽連五六個(gè)文件這時(shí)候才想起模式的價(jià)值。這份設(shè)計(jì)模式 PDF 的特別之處是沒(méi)有把二十三個(gè)模式平鋪著念一遍而是先把 SOLID 五原則和 UML 類圖的六種關(guān)系講透再挑單例、觀察者、策略、代理、裝飾這五個(gè)實(shí)際出場(chǎng)率最高的模式逐一帶類圖和可運(yùn)行代碼。適合兩類人一類是剛掌握繼承和多態(tài)、想在老項(xiàng)目里動(dòng)手重構(gòu)的開(kāi)發(fā)者另一類是被“需求一改連鎖改”折磨過(guò)、想弄明白邊界到底在哪的從業(yè)者。讀的時(shí)候建議按第 4 章的代碼順序從頭敲一遍敲完再回頭看原則部分理解會(huì)完全不一樣。2. 設(shè)計(jì)模式的原則SOLID 五原則落進(jìn)代碼的判定標(biāo)準(zhǔn)選模式之前得先過(guò)原則。這份資料把原則放在模式前面是有道理的原則是判斷“該不該用模式”的尺子模式只是尺子量完之后的具體方案。五條原則單拎出來(lái)都不難懂難的是合在一起用的時(shí)候怎么取舍。資料里也引了那本經(jīng)典書(shū)上的原始建議——不要為了套模式而用模式要從實(shí)際問(wèn)題出發(fā)。備查的書(shū)可以配兩本互補(bǔ)一本圖解風(fēng)格的 Head First 系列用來(lái)建立直觀印象一本實(shí)踐導(dǎo)向的 Effective Java 用來(lái)校正編碼習(xí)慣。2.1 單一職責(zé)與開(kāi)閉兩個(gè)變化源就要拆類單一職責(zé)原則第一句話是“一個(gè)類應(yīng)該只有一個(gè)引起它變化的原因”。問(wèn)題由來(lái)很直白一個(gè)訂單類既管金額計(jì)算、又管校驗(yàn)、還管數(shù)據(jù)庫(kù)讀寫(xiě)價(jià)格規(guī)則一變要改它換數(shù)據(jù)庫(kù)還要改它一個(gè)類背上兩個(gè)變化源測(cè)試時(shí)牽一發(fā)動(dòng)全身。解決方案就是按變化源拆類計(jì)算邏輯放一個(gè)類存取邏輯放另一個(gè)類各自獨(dú)立演化。判斷標(biāo)準(zhǔn)也很簡(jiǎn)單寫(xiě)需求的時(shí)候問(wèn)一句“這次改動(dòng)是因?yàn)槭裁丛虬l(fā)生的”如果同一個(gè)類因?yàn)閮蓚€(gè)不同原因都要改就該拆了。開(kāi)閉原則要求軟件實(shí)體對(duì)擴(kuò)展開(kāi)放、對(duì)修改關(guān)閉。常見(jiàn)做法是定義一個(gè)抽象接口固定行為模板新業(yè)務(wù)走新子類老代碼一行不動(dòng)。最常見(jiàn)的落地場(chǎng)景是支付渠道接入class IPayment { public: virtual ~IPayment() default; virtual bool pay(double amount) 0; virtual std::string channel_name() const 0; }; class WechatPayment : public IPayment { public: bool pay(double amount) override { // 微信支付請(qǐng)求邏輯 return true; } std::string channel_name() const override { return Wechat; } }; class OrderService { private: std::shared_ptrIPayment payment_; public: explicit OrderService(std::shared_ptrIPayment p) : payment_(std::move(p)) {} void checkout(double amount) { if (payment_-pay(amount)) { // 更新訂單狀態(tài) } } };這段代碼的邏輯是OrderService 只依賴 IPayment 抽象支付渠道是構(gòu)造時(shí)注入的。新增渠道時(shí)只需要新建一個(gè)實(shí)現(xiàn)類OrderService 和既有渠道代碼完全不用碰。參數(shù)說(shuō)明里有幾個(gè)點(diǎn)值得注意構(gòu)造參數(shù)用 shared_ptr 而不是裸指針是為了讓生命周期由調(diào)用方和 shared_ptr 共同管理pay 方法返回 bool 表示結(jié)果調(diào)用方據(jù)此決定后續(xù)流程。這就是對(duì)修改關(guān)閉——老代碼一行不改新功能照樣進(jìn)去。2.2 依賴倒置與接口隔離抽象界的紅線和接口瘦身依賴倒置原則說(shuō)的是高層模塊不依賴低層模塊兩者都依賴抽象。用發(fā)送通知的場(chǎng)景最容易說(shuō)清楚業(yè)務(wù)層不該直接 new 一個(gè)短信發(fā)送器而應(yīng)該依賴一個(gè)“能發(fā)消息”的抽象。代碼示范如下class IMessageSender { public: virtual ~IMessageSender() default; virtual void send(const std::string title, const std::string body) 0; }; class SmsSender : public IMessageSender { public: void send(const std::string title, const std::string body) override { // 短信網(wǎng)關(guān)調(diào)用 } }; class NoticeService { public: explicit NoticeService(std::shared_ptrIMessageSender sender) : sender_(std::move(sender)) {} void publish(const std::string title, const std::string body) { sender_-send(title, body); } private: std::shared_ptrIMessageSender sender_; };NoticeService 不關(guān)心你用的短信還是郵件它只認(rèn) IMessageSender 這個(gè)抽象。換實(shí)現(xiàn)的時(shí)候組裝層 new 一個(gè)別的 Sender 傳進(jìn)去就行業(yè)務(wù)代碼零改動(dòng)。這里有一個(gè)容易忽略的點(diǎn)IMessageSender 的接口粒度很關(guān)鍵如果把“查詢余額”“獲取發(fā)送報(bào)告”也塞進(jìn)這個(gè)接口NoticeService 就被迫依賴它用不上的能力這就是接口隔離原則要管的事。接口隔離原則的典型病狀是“胖接口”一個(gè) Player 接口同時(shí)有 play、record、pause、save一個(gè)只負(fù)責(zé)播放的類也被逼著實(shí)現(xiàn) record 和 save最后只能空實(shí)現(xiàn)然后拋異常。判斷標(biāo)準(zhǔn)就是看有沒(méi)有實(shí)現(xiàn)類被逼著空實(shí)現(xiàn)某個(gè)方法有就拆。拆成 Playable、Recordable、Saveable 三個(gè)小接口每個(gè)實(shí)現(xiàn)類只實(shí)現(xiàn)自己真正需要的部分。2.3 里氏替換子類行為不能比父類更“任性”里氏替換原則是所有繼承關(guān)系的安全紅線任何基類對(duì)象能出現(xiàn)的地方換成子類對(duì)象程序行為不應(yīng)該變。經(jīng)典反例就是正方形繼承長(zhǎng)方形。長(zhǎng)方形有寬高兩個(gè)獨(dú)立屬性正方形重寫(xiě) setWidth 時(shí)把高也改了基類的不變量被破壞。代碼示范如下class Rectangle { public: virtual void setWidth(int w) { width_ w; } virtual void setHeight(int h) { height_ h; } int area() const { return width_ * height_; } private: int width_ 0; int height_ 0; }; class Square : public Rectangle { public: void setWidth(int w) override { Rectangle::setWidth(w); Rectangle::setHeight(w); } void setHeight(int h) override { Rectangle::setWidth(h); Rectangle::setHeight(h); } }; void resize(Rectangle r, int w, int h) { r.setWidth(w); r.setHeight(h); // 期望 area() w * h }這段代碼的邏輯是resize 函數(shù)面對(duì) Rectangle 時(shí)行為正常一旦傳入 Square先 setWidth 后 setHeight高被覆蓋成寬度area 結(jié)果完全不符合預(yù)期。原因就是子類收緊了基類“寬高獨(dú)立變化”的不變量。解決方式不是硬套繼承而是讓 Square 組合一個(gè) Rectangle或者讓兩者都實(shí)現(xiàn)同一個(gè) IShape 接口。參數(shù)說(shuō)明里要留意“替換檢查”的思路每寫(xiě)一個(gè)子類把父類的所有方法調(diào)用一遍凡是出現(xiàn)“這個(gè)參數(shù)值在父類合法、在子類不合法”的情況繼承關(guān)系就要重新設(shè)計(jì)。3. UML 類圖關(guān)系六種關(guān)系的判定正解與代碼映射類圖關(guān)系是設(shè)計(jì)模式的“讀圖語(yǔ)言”。很多模式類圖看不懂卡住的原因不是模式本身而是泛化、實(shí)現(xiàn)、組合、聚合、關(guān)聯(lián)、依賴這六種關(guān)系的記號(hào)沒(méi)分清。這一章把每種關(guān)系的箭頭、線型、生命周期語(yǔ)義、代碼映射一次擺清楚。3.1 面向過(guò)程到面向?qū)ο箢悎D關(guān)系為什么非學(xué)不可面向過(guò)程時(shí)代函數(shù)操作數(shù)據(jù)數(shù)據(jù)和行為是分離的代碼之間的關(guān)系就是“誰(shuí)調(diào)用誰(shuí)”。面向?qū)ο蟀褦?shù)據(jù)和操作封裝進(jìn)類類與類之間要靠更精確的關(guān)系來(lái)表達(dá)協(xié)作方式誰(shuí)是父類、誰(shuí)持有誰(shuí)、誰(shuí)臨時(shí)用誰(shuí)。這兩種語(yǔ)義差別直接決定了代碼改一處會(huì)不會(huì)波及其他類。資料里專門(mén)用一節(jié)講類間關(guān)系綜述把關(guān)系分成縱向和橫向兩類——縱向是繼承層次的泛化和實(shí)現(xiàn)橫向是對(duì)象之間的組合、聚合、關(guān)聯(lián)和依賴這個(gè)分類對(duì)畫(huà)圖時(shí)快速定位很有用。3.2 六種關(guān)系的記號(hào)與箭頭從線型和菱形讀語(yǔ)義六種關(guān)系的類圖記號(hào)整理成一張表實(shí)際畫(huà)圖時(shí)照著查關(guān)系線型箭頭生命周期特征泛化Generalization實(shí)線空心三角箭頭指向父類繼承關(guān)系is-a實(shí)現(xiàn)Realization虛線空心三角箭頭指向接口類兌現(xiàn)接口契約組合Composition實(shí)線實(shí)心菱形在整體端同生共死整體銷毀部分跟著銷毀聚合Aggregation實(shí)線空心菱形在整體端整體與部分各自有獨(dú)立生命周期關(guān)聯(lián)Association實(shí)線可帶普通箭頭長(zhǎng)期持有的引用關(guān)系依賴Dependency虛線普通箭頭指向被依賴者臨時(shí)使用局部變量或函數(shù)參數(shù)判定順序建議是先把虛實(shí)線分開(kāi)再看箭頭形狀最后追問(wèn)生命周期。虛線上只有一種語(yǔ)義要么是實(shí)現(xiàn)要么是依賴實(shí)線上要重點(diǎn)區(qū)分組合和聚合這兩個(gè)最容易混。3.3 代碼倒推關(guān)系從成員變量和函數(shù)參數(shù)看類圖畫(huà)類圖最頭疼的是從現(xiàn)成代碼里倒推關(guān)系。下面這段代碼覆蓋了五種關(guān)系逐行看class Engine { public: Engine() { /* 內(nèi)部構(gòu)造持有油路狀態(tài) */ } }; class Car { private: Engine engine_; // 成員對(duì)象Car 銷毀它就不存在 - 組合 std::shared_ptrDriver driver_; // 外部傳入車報(bào)廢司機(jī)還在 - 聚合 public: explicit Car(std::shared_ptrDriver d) : driver_(std::move(d)) {} void refuel(FuelTank tank); // 函數(shù)參數(shù)臨時(shí)借用 - 依賴 }; class Sedan : public Car { // 繼承實(shí)體類 - 泛化 }; class HybridEngine : public Engine { // 繼承抽象/實(shí)體類語(yǔ)義二選一 };邏輯說(shuō)明engine_ 是 Car 的值成員Car 生命周期結(jié)束它必然結(jié)束這是組合的典型寫(xiě)法driver_ 是外部傳入的 shared_ptrCar 析構(gòu)不影響 Driver 對(duì)象本身所以是聚合refuel 的參數(shù) tank 只在函數(shù)體內(nèi)用臨時(shí)借用是依賴Sedan 繼承 Car 是泛化。參數(shù)說(shuō)明里有個(gè)容易踩的細(xì)節(jié)HybridEngine 如果繼承的是“引擎”這個(gè)抽象接口應(yīng)該畫(huà)成實(shí)現(xiàn)關(guān)系如果繼承的是 Engine 實(shí)體類才是泛化。同一個(gè)代碼寫(xiě)法在類圖里可能對(duì)應(yīng)兩種不同語(yǔ)義。3.4 組合與聚合的邊界生命周期就是判決書(shū)組合與聚合的差別一句話就能說(shuō)清組合關(guān)系里整體負(fù)責(zé)部分的創(chuàng)建和銷毀聚合關(guān)系里整體只是持有一個(gè)引用。典型的例子是游戲里的角色系統(tǒng)角色和技能模塊是組合角色被銷毀技能模塊連同冷卻狀態(tài)一起消失角色和裝備是聚合裝備卸下來(lái)還能給別的角色穿。代碼層面的判斷標(biāo)準(zhǔn)更直接部分是值成員、由構(gòu)造函數(shù)初始化、析構(gòu)函數(shù)釋放的是組合部分是通過(guò)參數(shù)傳入、由外部管理的是聚合。畫(huà)類圖時(shí)先問(wèn)“誰(shuí)擁有誰(shuí)的生命周期”答案出來(lái)關(guān)系就定了。4. 五個(gè)高頻模式實(shí)戰(zhàn)拆解從類圖到可運(yùn)行的 C 代碼這五個(gè)模式是實(shí)際項(xiàng)目里出場(chǎng)率最高的單例管全局狀態(tài)觀察者管事件解耦策略管算法替換代理管訪問(wèn)控制裝飾管職責(zé)疊加。每個(gè)模式給定義、類圖關(guān)系、應(yīng)用場(chǎng)景和可運(yùn)行代碼照著敲就能在自己項(xiàng)目里用。4.1 單例模式全局配置與引擎導(dǎo)演類單例模式確保一個(gè)類只有一個(gè)實(shí)例并提供全局訪問(wèn)點(diǎn)。類圖極其簡(jiǎn)單私有構(gòu)造函數(shù)加靜態(tài) instance() 方法類自己持有唯一實(shí)例。最常用的場(chǎng)景是全局配置和游戲引擎里的導(dǎo)演類導(dǎo)演負(fù)責(zé)場(chǎng)景切換、節(jié)點(diǎn)管理全引擎只需要一個(gè)。代碼示范class Config { public: static Config instance() { static Config cfg; // C11 起靜態(tài)局部變量初始化線程安全 return cfg; } std::string get(const std::string key) const { auto it values_.find(key); return it values_.end() ? : it-second; } void set(const std::string key, const std::string value) { values_[key] value; } private: Config() default; Config(const Config) delete; Config operator(const Config) delete; std::unordered_mapstd::string, std::string values_; };邏輯說(shuō)明C11 之后函數(shù)內(nèi)靜態(tài)局部變量的初始化由編譯器保證線程安全第一次調(diào)用 instance() 時(shí)只構(gòu)造一次不需要自己加鎖。構(gòu)造函數(shù)聲明為 private拷貝構(gòu)造和賦值運(yùn)算符 delete 掉外部無(wú)法復(fù)制出第二個(gè)實(shí)例。參數(shù)說(shuō)明里注意 set 和 get 操作的鍵值類型是字符串實(shí)際項(xiàng)目里可以模板化成任意類型。缺點(diǎn)是全局單例很難做單元測(cè)試隔離所以只建議用于配置、日志這類橫切關(guān)注點(diǎn)不要什么對(duì)象都往單例里塞。4.2 觀察者模式事件分發(fā)與監(jiān)聽(tīng)解耦觀察者模式定義一對(duì)多依賴主題狀態(tài)變化時(shí)自動(dòng)通知所有注冊(cè)的觀察者。應(yīng)用場(chǎng)景包括 UI 事件、網(wǎng)絡(luò)狀態(tài)變化、游戲里的事件監(jiān)聽(tīng)中心。類圖上 Subject 持有一個(gè)觀察者列表提供 attach、detach、notify 三個(gè)方法。代碼示范一個(gè)按事件類型分發(fā)的最小事件中心class IEventListener { public: virtual ~IEventListener() default; virtual void onEvent(int eventType, const std::string data) 0; }; class EventDispatcher { public: void addListener(int eventType, IEventListener* listener) { listeners_[eventType].push_back(listener); } void removeListener(int eventType, IEventListener* listener) { auto vec listeners_[eventType]; vec.erase(std::remove(vec.begin(), vec.end(), listener), vec.end()); } void dispatch(int eventType, const std::string data) { for (auto* listener : listeners_[eventType]) { listener-onEvent(eventType, data); } } private: std::unordered_mapint, std::vectorIEventListener* listeners_; };邏輯說(shuō)明listeners_ 用事件類型做 key每種事件掛一組監(jiān)聽(tīng)器業(yè)務(wù)模塊只需要在初始化時(shí)注冊(cè)自己關(guān)心的事件類型。removeListener 的設(shè)計(jì)是為了解析前先摘除失效監(jiān)聽(tīng)器避免懸垂指針。參數(shù)說(shuō)明里有兩個(gè)要點(diǎn)dispatch 是同步派發(fā)監(jiān)聽(tīng)器里的耗時(shí)邏輯會(huì)阻塞調(diào)用線程刪除操作要在遍歷副本或先摘除再派發(fā)直接在遍歷中刪除會(huì)迭代器失效。這就是游戲引擎里事件分發(fā)器的常見(jiàn)實(shí)現(xiàn)思路。4.3 策略模式算法運(yùn)行時(shí)替換與消除 if-else策略模式把一系列可互換的算法封裝成策略類運(yùn)行時(shí)可切換。類圖上 Context 持有 Strategy 引用二者通過(guò)抽象接口協(xié)作。典型的應(yīng)用場(chǎng)景是計(jì)算器算法切換、排序策略、格式化策略。代碼示范class CalcStrategy { public: virtual ~CalcStrategy() default; virtual int calc(int a, int b) const 0; }; class AddStrategy : public CalcStrategy { public: int calc(int a, int b) const override { return a b; } }; class SubStrategy : public CalcStrategy { public: int calc(int a, int b) const override { return a - b; } }; class Calculator { private: std::shared_ptrCalcStrategy strategy_; public: explicit Calculator(std::shared_ptrCalcStrategy s) : strategy_(std::move(s)) {} void set_strategy(std::shared_ptrCalcStrategy s) { strategy_ std::move(s); } int execute(int a, int b) const { return strategy_-calc(a, b); } };邏輯說(shuō)明Calculator 只認(rèn) CalcStrategy 抽象加減法是兩種可替換策略set_strategy 可以在運(yùn)行時(shí)切換算法。相比一長(zhǎng)串 if-else 判斷運(yùn)算符新增一種運(yùn)算只加一個(gè)策略類老代碼不用動(dòng)。參數(shù)說(shuō)明里注意策略對(duì)象用 shared_ptr 管理切換時(shí)舊策略在引用計(jì)數(shù)歸零后自動(dòng)釋放。這個(gè)模式的應(yīng)用不止于計(jì)算器原文里還提到汽車發(fā)動(dòng)機(jī)檔位——不同的檔位策略對(duì)應(yīng)不同的換擋算法發(fā)動(dòng)機(jī)控制器只依賴檔位策略接口。4.4 代理模式虛代理、智能代理與保護(hù)代理代理模式為另一個(gè)對(duì)象提供一個(gè)替身或占位符控制對(duì)這個(gè)對(duì)象的訪問(wèn)。類圖上 Proxy 和 RealSubject 實(shí)現(xiàn)同一個(gè)接口Proxy 內(nèi)部持有 RealSubject 的引用。按用途分三類虛代理延遲加載大對(duì)象智能代理加日志和引用計(jì)數(shù)保護(hù)代理控制訪問(wèn)權(quán)限。以圖片延遲加載為例class IImage { public: virtual ~IImage() default; virtual void draw() 0; }; class RealImage : public IImage { public: void draw() override { // 從磁盤(pán)加載圖片資源并繪制 } }; class ImageProxy : public IImage { private: std::unique_ptrRealImage real_; public: void draw() override { if (!real_) { real_ std::make_uniqueRealImage(); // 第一次 draw 才真正加載 } real_-draw(); } };邏輯說(shuō)明ImageProxy 和 RealImage 實(shí)現(xiàn)同一接口調(diào)用方無(wú)感知。虛代理的效果是延遲加載——對(duì)象創(chuàng)建時(shí)不加載資源第一次 draw 時(shí)才構(gòu)造 RealImage。參數(shù)說(shuō)明里 real_ 用 unique_ptr 持有生命周期完全由代理管理這是虛代理的標(biāo)準(zhǔn)寫(xiě)法。保護(hù)代理在 draw 之前加一層權(quán)限校驗(yàn)不通過(guò)直接返回訪問(wèn)邏輯和業(yè)務(wù)邏輯就分離開(kāi)了。4.5 裝飾模式職責(zé)疊加與包裝順序裝飾模式不修改原類通過(guò)包裝對(duì)象動(dòng)態(tài)疊加行為。類圖上 Decorator 持有 Component 引用并且實(shí)現(xiàn)同一接口層層包裝。經(jīng)典場(chǎng)景是飲品加料計(jì)費(fèi)咖啡基礎(chǔ)價(jià)加奶、加糖各加一份錢也可以用在日志增強(qiáng)、緩存疊加。代碼示范class Beverage { public: virtual ~Beverage() default; virtual double cost() const 0; }; class Espresso : public Beverage { public: double cost() const override { return 3.0; } }; class MilkDecorator : public Beverage { private: std::unique_ptrBeverage wrapped_; public: explicit MilkDecorator(std::unique_ptrBeverage b) : wrapped_(std::move(b)) {} double cost() const override { return wrapped_-cost() 0.5; } }; // 使用auto coffee std::make_uniqueMilkDecorator(std::make_uniqueEspresso());邏輯說(shuō)明MilkDecorator 持有被包裝的 Beveragecost() 先取內(nèi)層價(jià)格再加自己的價(jià)實(shí)現(xiàn)了職責(zé)疊加。包裝兩層就是加雙份奶包裝一層就是單份完全靠組合實(shí)現(xiàn)不用為每種組合建子類。參數(shù)說(shuō)明里注意 unique_ptr 不能拷貝構(gòu)造時(shí)用 std::move 轉(zhuǎn)移所有權(quán)疊加順序會(huì)影響最終行為這一點(diǎn)在實(shí)際項(xiàng)目中要約定統(tǒng)一方向。5. 設(shè)計(jì)模式實(shí)戰(zhàn)避坑五個(gè)最常見(jiàn)的翻車現(xiàn)場(chǎng)把模式看懂和把模式用好中間隔著不少坑。下面這五條是我見(jiàn)過(guò)或踩過(guò)的具體問(wèn)題每條按現(xiàn)象、原因、解決的順序?qū)懻罩挪槟苌僮邚澛贰?.1 單例不做線程保護(hù)多線程下拿到兩個(gè)實(shí)例現(xiàn)象多線程并發(fā)首次調(diào)用 instance()程序里出現(xiàn)了兩個(gè)不同地址的配置對(duì)象后續(xù)讀寫(xiě)數(shù)據(jù)錯(cuò)亂。原因如果用的是 C11 之前的經(jīng)典懶漢寫(xiě)法new 操作和賦值之間可以被其他線程插進(jìn)來(lái)double-check 在指令重排下也不可靠。解決統(tǒng)一用函數(shù)內(nèi)靜態(tài)局部變量C11 之后編譯器保證初始化線程安全。如果項(xiàng)目還在 C03 環(huán)境直接用餓漢式靜態(tài)成員不要自己手寫(xiě)加鎖。5.2 觀察者互聽(tīng)形成環(huán)一次派發(fā)直接棧溢出現(xiàn)象模塊 A 監(jiān)聽(tīng)事件 X模塊 B 監(jiān)聽(tīng)事件 YA 在 X 的處理里派發(fā) YB 在 Y 的處理里派發(fā) X一次外部觸發(fā)后兩個(gè)模塊互相調(diào)用棧很快被打爆。原因同步派發(fā)沒(méi)有遞歸深度限制事件環(huán)一旦形成就無(wú)限遞歸。解決事件總線加派發(fā)深度計(jì)數(shù)超過(guò)閾值直接丟棄或者在派發(fā)前先摘除當(dāng)前正在處理的監(jiān)聽(tīng)器。設(shè)計(jì)上也要避免兩個(gè)業(yè)務(wù)模塊直接互聽(tīng)對(duì)方事件盡量通過(guò)上層狀態(tài)協(xié)調(diào)。5.3 策略模式用早兩三個(gè)分支也抽象出五個(gè)文件現(xiàn)象一個(gè)方法里只有兩三種分支也建了策略接口、三個(gè)實(shí)現(xiàn)類加一個(gè)工廠代碼量翻倍改動(dòng)成本反而比 if-else 更高。原因把模式當(dāng)目的而不是手段忽略了對(duì)“變化頻率”的判斷。解決分支數(shù)超過(guò)四五個(gè)、算法還在穩(wěn)定增加時(shí)再上策略模式。兩個(gè)分支且基本不變就老實(shí)寫(xiě) if-else不要為了簡(jiǎn)歷上好看而過(guò)度設(shè)計(jì)。5.4 虛代理只做了一半延遲加載變成每次重建現(xiàn)象ImageProxy 的 draw 方法里 new RealImage 后直接畫(huà)畫(huà)完不保存引用下一次 draw 又 new 一次加載了十次資源。原因代理類的成員沒(méi)有緩存創(chuàng)建好的真實(shí)對(duì)象創(chuàng)建代碼寫(xiě)在了調(diào)用路徑上。解決用成員 unique_ptr 持有真實(shí)對(duì)象判空創(chuàng)建創(chuàng)建后復(fù)用。關(guān)鍵參數(shù)是“創(chuàng)建后的對(duì)象必須賦值給成員”不能只在局部變量里存在。虛代理的價(jià)值在“加載一次”沒(méi)緩存就等于沒(méi)做代理。5.5 裝飾器包裝順序顛倒疊加效果差出兩倍現(xiàn)象同樣的兩個(gè)裝飾器先包 A 再包 B 與先包 B 再包 A最終計(jì)算結(jié)果完全不同費(fèi)用多出一截。原因裝飾器逐層包裹每層都在內(nèi)層基礎(chǔ)上疊加方向決定了結(jié)果。解決把疊加規(guī)則寫(xiě)進(jìn)文檔按業(yè)務(wù)語(yǔ)義約定統(tǒng)一包裝順序。比如先加基礎(chǔ)料、再加混合料、最后加額外料所有調(diào)用點(diǎn)必須遵循同一方向。參數(shù)說(shuō)明里這條不是代碼 bug是設(shè)計(jì)規(guī)范問(wèn)題比改代碼更花時(shí)間。6. 認(rèn)出模式到用對(duì)模式代碼走查里的三條習(xí)慣6.1 第一習(xí)慣先數(shù)變化源再?zèng)Q定動(dòng)不動(dòng)模式走查代碼時(shí)拿到一個(gè)類第一件事是問(wèn)“這個(gè)類會(huì)因?yàn)閹讉€(gè)原因發(fā)生變化”。兩個(gè)以上就拆類拆完看清變化源再?zèng)Q定用哪個(gè)模式。不要一上來(lái)就翻模式表模式是尺子變化點(diǎn)才是要量的尺寸。6.2 第二習(xí)慣繼承樹(shù)超過(guò)三層做一遍替換檢查繼承超過(guò)三層每層都可能收窄父類不變量。把所有父類方法逐一用子類實(shí)例調(diào)用一遍凡是出現(xiàn)“父類合法、子類不合法”的邊界立刻重構(gòu)。里氏替換不是理論條款是走查清單里的一條硬檢查。6.3 第三習(xí)慣讓模式名直接出現(xiàn)在類名里Config 單例就寫(xiě) Config::instance()代理類就叫 ImageProxy裝飾器就叫 MilkDecorator。類名自帶模式信息新同事看代碼一眼就知道設(shè)計(jì)意圖走查時(shí)也不用翻文檔猜。模式價(jià)值一半在結(jié)構(gòu)另一半在可讀的命名。從那以后我每次重構(gòu)前都強(qiáng)制把變化點(diǎn)列出來(lái)再對(duì)著“變化源 → 模式映射”走一遍該用策略的用策略、該用裝飾的用裝飾該什么都不用的也不硬套。這套流程幫我擋掉了不少未來(lái)三個(gè)月的返工希望你也能用上。這份 PDF 適合放在手邊當(dāng)參考下載后按第 2 章到第 4 章的順序過(guò)一遍代碼收獲會(huì)比通讀全部二十三個(gè)模式大得多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取