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