簡(jiǎn)介這份《大話設(shè)計(jì)模式復(fù)習(xí)》文檔面向具備一定面向?qū)ο缶幊袒A(chǔ)、工作1至3年的研發(fā)人員系統(tǒng)梳理設(shè)計(jì)模式的核心知識(shí)體系。內(nèi)容從設(shè)計(jì)模式的定義、分類、特點(diǎn)與應(yīng)用場(chǎng)景切入詳細(xì)講解單一職責(zé)、開放-封閉、依賴倒轉(zhuǎn)、里氏代換、迪米特法則、合成/聚合及接口隔離七大設(shè)計(jì)原則并深入剖析抽象工廠、策略、外觀、適配器、組合、單例、中介者七種常用模式以及其余十五種模式每種均配以定義、UML類圖、基礎(chǔ)代碼與實(shí)例。文檔還橫向?qū)Ρ炔煌Ｊ降牟町惪偨Y(jié)模式選擇的關(guān)鍵維度并附練習(xí)題與模擬試卷輔助鞏固。資源包為單個(gè)docx文件約3.66MB結(jié)構(gòu)完整、目錄清晰便于按章節(jié)檢索學(xué)習(xí)。目前已有191人學(xué)習(xí)適合希望提升代碼可維護(hù)性、可擴(kuò)展性與復(fù)用能力并在實(shí)際項(xiàng)目中靈活選用設(shè)計(jì)模式的開發(fā)者參考。1. 從一次代碼評(píng)審翻車說起為什么設(shè)計(jì)模式復(fù)習(xí)不能只背 23 個(gè)名字去年幫一個(gè)做企業(yè)級(jí)管理系統(tǒng)的團(tuán)隊(duì)看代碼需求是加一種新的支付渠道。按理說這是個(gè)小改動(dòng)結(jié)果開發(fā)同學(xué)在PaymentService里又塞了一個(gè)else if那個(gè)類已經(jīng)膨脹到 1800 多行改完之后回歸測(cè)試直接炸了三個(gè)老渠道。問題不在他不會(huì)寫代碼而在于他腦子里沒有「策略模式」這個(gè)可替換的抽象層——所有渠道邏輯硬編碼在一個(gè)類里擴(kuò)展一次就動(dòng)一次核心邏輯開放-封閉原則形同虛設(shè)。這就是設(shè)計(jì)模式復(fù)習(xí)這件事最尷尬的地方很多人能背出 23 個(gè)模式的名字和分類但真到項(xiàng)目里該用的時(shí)候想不起來或者用錯(cuò)了地方。這份《大話設(shè)計(jì)模式復(fù)習(xí)》文檔的價(jià)值恰恰在于它不是干巴巴地列定義而是把七大設(shè)計(jì)原則、七大重點(diǎn)模式抽象工廠、策略、外觀、適配器、組合、單例、中介者和剩余 15 種模式全部配了 UML 類圖、基礎(chǔ)代碼和真實(shí)實(shí)例最后還做了易混淆模式的橫向?qū)Ρ群湍M試卷。它適合兩類人一是工作 1-3 年、想從「能寫功能」進(jìn)階到「能設(shè)計(jì)結(jié)構(gòu)」的開發(fā)者二是正在準(zhǔn)備軟件工程方向課程設(shè)計(jì)或畢設(shè)答辯、需要一套完整模式應(yīng)用綜述來支撐方案的同學(xué)。下面我按「需求怎么立 → 結(jié)構(gòu)怎么設(shè)計(jì) → 代碼怎么落地 → 怎么驗(yàn)收」這條線把這份復(fù)習(xí)資料拆成一份可以直接照著走的方案。2. 需求與技術(shù)選型先想清楚復(fù)習(xí)設(shè)計(jì)模式到底要解決什么問題2.1 復(fù)習(xí)目標(biāo)不是記住 23 個(gè)名字而是建立「問題→模式」的映射大多數(shù)人復(fù)習(xí)設(shè)計(jì)模式的失敗路徑是這樣的打開文檔從「單例模式」開始看看到「訪問者模式」已經(jīng)忘了前面一半合上文檔腦子里只剩「好像有個(gè)工廠」。根本原因是把設(shè)計(jì)模式當(dāng)成了知識(shí)點(diǎn)來背而不是當(dāng)成工具箱來用。正確的復(fù)習(xí)目標(biāo)應(yīng)該反過來定先明確你手頭有哪些典型問題場(chǎng)景再倒推該用哪個(gè)模式。比如「對(duì)象創(chuàng)建邏輯復(fù)雜且需要解耦」對(duì)應(yīng)工廠系列「算法需要運(yùn)行時(shí)切換」對(duì)應(yīng)策略模式「子系統(tǒng)接口太復(fù)雜需要簡(jiǎn)化」對(duì)應(yīng)外觀模式「不兼容接口需要轉(zhuǎn)換」對(duì)應(yīng)適配器模式。這份文檔里七大重點(diǎn)模式之所以被單獨(dú)拎出來分析就是因?yàn)樗鼈冊(cè)谡鎸?shí)項(xiàng)目中的出現(xiàn)頻率最高抽象工廠管對(duì)象族創(chuàng)建、策略管算法互換、外觀管接口簡(jiǎn)化、適配器管接口轉(zhuǎn)換、組合管樹形結(jié)構(gòu)、單例管全局唯一、中介者管多對(duì)象解耦——每一個(gè)都對(duì)應(yīng)一類反復(fù)出現(xiàn)的工程問題。所以復(fù)習(xí)的第一件事是給自己列一張「我最近寫過的代碼里哪些地方改起來最痛苦」的清單然后帶著這些問題去對(duì)照模式。這比從頭背到尾效率高得多。2.2 技術(shù)棧與文檔結(jié)構(gòu)Java 為主、C 補(bǔ)充UML 貫穿始終這份復(fù)習(xí)資料的技術(shù)選型很明確主體代碼用 Java 實(shí)現(xiàn)抽象工廠和策略模式的實(shí)例部分有 C 版本作為對(duì)照。這個(gè)選擇是合理的因?yàn)?Java 的接口和抽象類機(jī)制天然適合演示面向?qū)ο蟮脑O(shè)計(jì)模式而 C 的多態(tài)和虛函數(shù)則能幫你理解模式在更底層語言里的形態(tài)差異。文檔的整體結(jié)構(gòu)分四層層次內(nèi)容作用基礎(chǔ)層設(shè)計(jì)模式定義、分類、特點(diǎn)、應(yīng)用場(chǎng)景、UML 類圖規(guī)范建立統(tǒng)一術(shù)語和表達(dá)方式原則層七大設(shè)計(jì)原則SRP、OCP、DIP、LSP、LOD、CARP、ISP提供評(píng)判設(shè)計(jì)好壞的標(biāo)準(zhǔn)重點(diǎn)模式層抽象工廠、策略、外觀、適配器、組合、單例、中介者高頻模式深度剖析含完整代碼擴(kuò)展與對(duì)比層剩余 15 種模式 易混淆模式對(duì)比 練習(xí)題與模擬試卷補(bǔ)齊知識(shí)面強(qiáng)化辨析能力這個(gè)結(jié)構(gòu)的聰明之處在于先用原則建立判斷標(biāo)準(zhǔn)再用重點(diǎn)模式打透幾個(gè)典型場(chǎng)景最后用對(duì)比表把容易混淆的模式區(qū)分開。復(fù)習(xí)的時(shí)候如果時(shí)間緊可以按「原則 → 七大模式 → 對(duì)比表 → 模擬試卷」的順序走把剩余 15 種模式作為查閱手冊(cè)而不是精讀材料。2.3 適用人群與前置知識(shí)會(huì)寫類不等于會(huì)做設(shè)計(jì)這份資料明確說了適合「具備一定編程基礎(chǔ)、對(duì)面向?qū)ο笤O(shè)計(jì)有了解」的研發(fā)人員。翻譯一下就是你得能看懂 Java 的 interface、abstract class、繼承和多態(tài)知道什么是 UML 類圖中的泛化、實(shí)現(xiàn)、關(guān)聯(lián)、聚合、組合關(guān)系。如果這些還不熟直接看模式代碼會(huì)很吃力。具體來說前置知識(shí)包括三塊一是面向?qū)ο笕筇匦苑庋b、繼承、多態(tài)的實(shí)際運(yùn)用經(jīng)驗(yàn)不是概念背誦二是 UML 類圖的基本讀圖能力至少能分清實(shí)線空心三角是繼承、虛線空心三角是實(shí)現(xiàn)三是至少寫過 3000 行以上的項(xiàng)目代碼否則你很難體會(huì)到「這個(gè)類改起來真痛苦」是什么感覺也就無法理解模式要解決的真實(shí)痛點(diǎn)。提示如果你目前只寫過課程作業(yè)級(jí)別的小程序建議先找一個(gè)開源項(xiàng)目讀一讀它的分層結(jié)構(gòu)再回來復(fù)習(xí)模式效果會(huì)好很多。3. 總體設(shè)計(jì)七大原則打底、三類模式分層、對(duì)比表收口的復(fù)習(xí)框架3.1 七大設(shè)計(jì)原則是判斷模式用得好不好的標(biāo)尺文檔把七大原則放在模式分析之前這個(gè)順序不能顛倒。因?yàn)樵O(shè)計(jì)模式是「術(shù)」設(shè)計(jì)原則是「道」——你不知道什么是好的設(shè)計(jì)就沒法判斷一個(gè)模式用得對(duì)不對(duì)。七大原則里最核心的是三條開放-封閉原則OCP要求軟件實(shí)體對(duì)擴(kuò)展開放、對(duì)修改關(guān)閉這是所有模式追求的終極目標(biāo)依賴倒轉(zhuǎn)原則DIP要求高層模塊和低層模塊都依賴抽象這是實(shí)現(xiàn) OCP 的主要手段單一職責(zé)原則SRP要求一個(gè)類只有一個(gè)引起變化的原因這是控制類膨脹的第一道防線。剩下四條各有側(cè)重里氏代換原則LSP保證子類能替換父類而不破壞行為契約迪米特法則LOD要求對(duì)象之間盡量少直接通信、通過中間人轉(zhuǎn)發(fā)合成/聚合原則CARP優(yōu)先用組合而非繼承來降低耦合接口隔離原則ISP要求把大接口拆成小接口避免依賴不需要的方法。復(fù)習(xí)的時(shí)候我建議這樣用每看完一個(gè)模式回頭對(duì)照它「應(yīng)用了哪些原則、違反了哪些原則」。比如文檔里抽象工廠模式的分析就明確寫了——它應(yīng)用了依賴倒轉(zhuǎn)原則和合成/聚合原則但在新增產(chǎn)品等級(jí)結(jié)構(gòu)時(shí)會(huì)違反開放-封閉原則。這種「有得有失」的分析才是真正理解模式的關(guān)鍵而不是簡(jiǎn)單地說「這個(gè)模式好」。3.2 三類模式的分層邏輯創(chuàng)建型管怎么生、結(jié)構(gòu)型管怎么拼、行為型管怎么動(dòng)23 種設(shè)計(jì)模式按目的分為三大類這個(gè)分類不是隨便分的它對(duì)應(yīng)了軟件設(shè)計(jì)中三個(gè)最基本的問題維度創(chuàng)建型模式5 種解決的是「對(duì)象怎么創(chuàng)建」的問題。單例模式保證全局唯一實(shí)例工廠方法模式把創(chuàng)建延遲到子類抽象工廠模式創(chuàng)建整個(gè)產(chǎn)品族建造者模式分步構(gòu)建復(fù)雜對(duì)象原型模式通過克隆創(chuàng)建新對(duì)象。它們的共同目標(biāo)是把對(duì)象的創(chuàng)建和使用分離讓客戶端不依賴具體類。結(jié)構(gòu)型模式7 種解決的是「類和對(duì)象怎么組合」的問題。適配器模式轉(zhuǎn)換接口裝飾器模式動(dòng)態(tài)添加職責(zé)代理模式控制訪問外觀模式簡(jiǎn)化子系統(tǒng)接口橋接模式分離抽象與實(shí)現(xiàn)組合模式處理樹形結(jié)構(gòu)享元模式共享細(xì)粒度對(duì)象。它們的共同目標(biāo)是通過組合關(guān)系構(gòu)建更靈活的結(jié)構(gòu)。行為型模式10 種解決的是「對(duì)象之間怎么交互和分配職責(zé)」的問題。策略模式封裝可互換算法觀察者模式建立一對(duì)多依賴通知命令模式把請(qǐng)求封裝為對(duì)象狀態(tài)模式讓對(duì)象在內(nèi)部狀態(tài)改變時(shí)改變行為責(zé)任鏈模式沿鏈傳遞請(qǐng)求模板方法模式定義算法骨架迭代器模式順序訪問集合元素中介者模式集中管理對(duì)象間交互備忘錄模式捕獲和恢復(fù)狀態(tài)訪問者模式在不改變?cè)仡惖那疤嵯露x新操作。復(fù)習(xí)時(shí)按這個(gè)分層走每類先抓 2-3 個(gè)最常用的模式吃透再擴(kuò)展到同類其他模式比按字母順序或難度順序背要高效得多。3.3 對(duì)比表是復(fù)習(xí)收口的關(guān)鍵工具文檔最后一部分的對(duì)比表是我認(rèn)為最有價(jià)值的內(nèi)容之一。它把容易混淆的模式成對(duì)或成組地放在一起比較簡(jiǎn)單工廠 vs 工廠方法 vs 抽象工廠從「一個(gè)工廠類管所有產(chǎn)品」到「一個(gè)工廠接口管一類產(chǎn)品」再到「一個(gè)工廠接口管一族產(chǎn)品」抽象層級(jí)逐步提升適配器 vs 裝飾器 vs 代理三者都涉及「包裝」一個(gè)對(duì)象但適配器改變接口、裝飾器增強(qiáng)功能、代理控制訪問策略 vs 狀態(tài)兩者都通過組合持有可變行為但策略是客戶端主動(dòng)選擇算法狀態(tài)是對(duì)象內(nèi)部狀態(tài)變化驅(qū)動(dòng)行為切換觀察者 vs 中介者觀察者是一對(duì)多的廣播通知中介者是多對(duì)多的集中協(xié)調(diào)責(zé)任鏈 vs 中介者責(zé)任鏈?zhǔn)钦?qǐng)求沿鏈傳遞直到被處理中介者是所有交互都經(jīng)過中心節(jié)點(diǎn)這些對(duì)比不是讓你背結(jié)論而是讓你在選型時(shí)能快速排除不合適的選項(xiàng)。比如你面對(duì)一個(gè)「需要?jiǎng)討B(tài)切換算法」的場(chǎng)景看到「策略 vs 狀態(tài)」的對(duì)比就知道如果切換是客戶端主動(dòng)發(fā)起的選策略如果是對(duì)象內(nèi)部狀態(tài)變化觸發(fā)的選狀態(tài)。4. 核心模塊實(shí)現(xiàn)從抽象工廠到中介者的代碼落地與設(shè)計(jì)說明4.1 抽象工廠模式可移植數(shù)據(jù)訪問層的完整實(shí)現(xiàn)抽象工廠是文檔里篇幅最長(zhǎng)的模式分析因?yàn)樗婕暗漠a(chǎn)品族概念最復(fù)雜。文檔給的實(shí)例是「可移植數(shù)據(jù)訪問程序」——同一套業(yè)務(wù)邏輯需要支持 SQL Server 和 Access 兩種數(shù)據(jù)庫每種數(shù)據(jù)庫都要?jiǎng)?chuàng)建 User 和 Department 兩類對(duì)象。先看抽象工廠接口和具體工廠的定義// 抽象工廠接口聲明創(chuàng)建產(chǎn)品族的方法 public interface IFactory { IUser CreateUser(); // 創(chuàng)建 User 對(duì)象的接口 IDepartment CreateDepartment(); // 創(chuàng)建 Department 對(duì)象的接口 } // SQL Server 具體工廠創(chuàng)建 SQL Server 產(chǎn)品族 public class SqlServerFactory implements IFactory { public IUser CreateUser() { return new SqlserverUser(); // 返回 SQL Server 的 User 實(shí)現(xiàn) } public IDepartment CreateDepartment() { return new SqlserverDepartment(); } } // Access 具體工廠創(chuàng)建 Access 產(chǎn)品族 public class AccessFactory implements IFactory { public IUser CreateUser() { return new AccessUser(); } public IDepartment CreateDepartment() { return new AccessDepartment(); } }這段代碼的關(guān)鍵設(shè)計(jì)點(diǎn)在于客戶端只依賴IFactory、IUser、IDepartment三個(gè)抽象完全不感知具體用的是哪個(gè)數(shù)據(jù)庫。切換數(shù)據(jù)庫時(shí)只需要換一個(gè)工廠實(shí)例業(yè)務(wù)代碼一行不用改。// 客戶端代碼只依賴抽象接口 public class Client { public static void main(String[] args) { // 切換數(shù)據(jù)庫只需改這一行 IFactory factory new SqlServerFactory(); // IFactory factory new AccessFactory(); IUser iu factory.CreateUser(); iu.Insert(new User()); iu.GetUser(1); IDepartment id factory.CreateDepartment(); id.Insert(new Department()); id.GetDepartment(1); } }參數(shù)說明IFactory是抽象工廠接口SqlServerFactory和AccessFactory是具體工廠IUser和IDepartment是抽象產(chǎn)品接口SqlserverUser、AccessUser、SqlserverDepartment、AccessDepartment是具體產(chǎn)品?？蛻舳送ㄟ^工廠接口獲取產(chǎn)品通過產(chǎn)品接口調(diào)用業(yè)務(wù)方法。這個(gè)模式的優(yōu)缺點(diǎn)文檔寫得很清楚優(yōu)點(diǎn)是分離接口和實(shí)現(xiàn)、客戶端與具體產(chǎn)品解耦、增加產(chǎn)品族時(shí)符合依賴倒轉(zhuǎn)原則缺點(diǎn)是增加新的產(chǎn)品等級(jí)結(jié)構(gòu)比如再加一個(gè)IScore接口時(shí)需要修改抽象工廠和所有具體工廠違反開放-封閉原則。所以抽象工廠適合「產(chǎn)品族穩(wěn)定、產(chǎn)品等級(jí)結(jié)構(gòu)可能擴(kuò)展」的場(chǎng)景反過來就要慎重。4.2 策略模式商場(chǎng)收銀系統(tǒng)的算法互換設(shè)計(jì)策略模式解決的是「算法需要運(yùn)行時(shí)切換」的問題。文檔用的實(shí)例是商場(chǎng)收銀系統(tǒng)不同折扣策略對(duì)應(yīng)不同的收費(fèi)算法。// 策略接口聲明算法方法 interface Strategy { void doAlgorithm(); } // 具體策略 A class StrategyA implements Strategy { public void doAlgorithm() { // 算法 A 的具體實(shí)現(xiàn) } } // 上下文持有策略對(duì)象委托執(zhí)行 class Context { private Strategy strategy; // 運(yùn)行時(shí)注入具體策略 public void setStrategy(Strategy s) { strategy s; } public void executeStrategy() { strategy.doAlgorithm(); // 委托給具體策略執(zhí)行 } }設(shè)計(jì)說明Context類是整個(gè)模式的核心它持有一個(gè)Strategy接口的引用但不關(guān)心具體是哪個(gè)實(shí)現(xiàn)。客戶端通過setStrategy()方法在運(yùn)行時(shí)注入不同的策略對(duì)象然后統(tǒng)一調(diào)用executeStrategy()。這樣新增一種折扣算法只需要實(shí)現(xiàn)一個(gè)新的Strategy子類不需要修改Context和已有策略類完全符合開放-封閉原則。文檔還給了 C 版本的收銀系統(tǒng)實(shí)現(xiàn)核心思路一致只是用虛函數(shù)替代了 Java 的接口。對(duì)比看兩種語言的實(shí)現(xiàn)能幫你理解策略模式的本質(zhì)不管語言怎么變「定義算法族 → 封裝每個(gè)算法 → 使它們可互換」這個(gè)結(jié)構(gòu)是不變的。策略模式應(yīng)用的設(shè)計(jì)原則包括開放-封閉原則新增策略不改已有代碼、依賴倒轉(zhuǎn)原則Context 依賴 Strategy 抽象而非具體策略、合成/聚合原則Context 通過組合持有 Strategy 而非繼承。它和狀態(tài)模式的區(qū)別在于策略模式的切換由客戶端主動(dòng)發(fā)起狀態(tài)模式的切換由對(duì)象內(nèi)部狀態(tài)變化驅(qū)動(dòng)。4.3 單例模式與中介者模式全局唯一與多對(duì)多解耦單例模式是文檔里篇幅較長(zhǎng)的另一個(gè)模式因?yàn)樗膶?shí)現(xiàn)方式有多種餓漢式、懶漢式、雙重檢查鎖、靜態(tài)內(nèi)部類、枚舉每種都有線程安全和性能上的取舍。核心目標(biāo)只有一個(gè)保證一個(gè)類只有一個(gè)實(shí)例并提供一個(gè)全局訪問點(diǎn)。// 雙重檢查鎖實(shí)現(xiàn)兼顧線程安全和延遲加載 public class Singleton { // volatile 禁止指令重排序防止拿到未初始化完的對(duì)象 private static volatile Singleton instance; private Singleton() {} // 私有構(gòu)造禁止外部 new public static Singleton getInstance() { if (instance null) { // 第一次檢查避免不必要的同步 synchronized (Singleton.class) { if (instance null) { // 第二次檢查確保只創(chuàng)建一次 instance new Singleton(); } } } return instance; } }參數(shù)說明volatile關(guān)鍵字是必須的它禁止 JVM 指令重排序防止在instance new Singleton()這行代碼中對(duì)象還沒初始化完成就把引用賦值給instance導(dǎo)致其他線程拿到一個(gè)半成品對(duì)象。這是單例模式最容易翻車的地方也是面試高頻考點(diǎn)。中介者模式解決的是「多個(gè)對(duì)象之間交互復(fù)雜、耦合嚴(yán)重」的問題。文檔里的定義是用一個(gè)中介對(duì)象來封裝一系列的對(duì)象交互使各對(duì)象不需要顯式地相互引用。同事類之間不直接通信全部通過中介者轉(zhuǎn)發(fā)。// 抽象中介者 abstract class Mediator { public abstract void send(String message, Colleague colleague); } // 抽象同事類 abstract class Colleague { protected Mediator mediator; public Colleague(Mediator mediator) { this.mediator mediator; } } // 具體同事類 A class ConcreteColleagueA extends Colleague { public ConcreteColleagueA(Mediator mediator) { super(mediator); } public void send(String message) { mediator.send(message, this); // 通過中介者轉(zhuǎn)發(fā) } public void notify(String message) { // 接收來自中介者的通知 } }設(shè)計(jì)說明中介者模式把多對(duì)多的網(wǎng)狀依賴變成了一對(duì)多的星形依賴同事類之間不再直接引用所有交互都經(jīng)過中介者。這符合迪米特法則——兩個(gè)類若不必直接通信就不發(fā)生直接作用。代價(jià)是中介者本身可能變得很復(fù)雜如果同事類太多、交互邏輯太雜中介者會(huì)膨脹成一個(gè)「上帝類」。所以中介者模式適合交互規(guī)則明確且相對(duì)穩(wěn)定的場(chǎng)景不適合交互邏輯頻繁變化的場(chǎng)景。5. 避坑與常見問題復(fù)習(xí)設(shè)計(jì)模式最容易翻車的五個(gè)點(diǎn)5.1 把模式當(dāng)模板硬套為了用而用現(xiàn)象項(xiàng)目里明明只有一個(gè)數(shù)據(jù)庫、一種支付方式卻非要上抽象工廠和策略模式代碼量翻了三倍維護(hù)的人一臉懵。原因把「用了多少模式」當(dāng)成了設(shè)計(jì)能力的體現(xiàn)忽略了模式是用來解決特定問題的工具不是目的。解決每次想引入一個(gè)模式之前先問自己三個(gè)問題——不用這個(gè)模式會(huì)怎樣未來真的會(huì)有多種實(shí)現(xiàn)嗎引入后代碼是更簡(jiǎn)單還是更復(fù)雜了如果答案是「不用也能跑」「短期內(nèi)不會(huì)擴(kuò)展」「引入后更復(fù)雜」那就先別用。模式是等到痛點(diǎn)出現(xiàn)時(shí)才上的不是提前鋪路的。5.2 混淆策略模式和狀態(tài)模式現(xiàn)象寫了一個(gè)策略模式但策略的切換邏輯寫在 Context 內(nèi)部根據(jù)某個(gè)字段值自動(dòng)切換結(jié)果和狀態(tài)模式長(zhǎng)得一模一樣自己都說不清用的是哪個(gè)。原因兩個(gè)模式的類圖結(jié)構(gòu)幾乎相同都是 Context 持有抽象接口接口有多個(gè)實(shí)現(xiàn)區(qū)別只在「誰驅(qū)動(dòng)切換」和「切換的語義」。解決記住一條判斷標(biāo)準(zhǔn)——如果切換是客戶端主動(dòng)選擇的比如用戶選了「打八折」用策略模式如果切換是對(duì)象內(nèi)部狀態(tài)變化自動(dòng)觸發(fā)的比如訂單從「待支付」變成「已支付」后行為自動(dòng)改變用狀態(tài)模式。策略模式的 Context 通常提供setStrategy()方法供外部調(diào)用狀態(tài)模式的 Context 通常內(nèi)部管理狀態(tài)轉(zhuǎn)換。5.3 單例模式忘記處理線程安全現(xiàn)象本地測(cè)試一切正常上線后偶爾出現(xiàn)兩個(gè)單例實(shí)例導(dǎo)致配置不一致或資源重復(fù)初始化。原因用了懶漢式但沒有加鎖或者加了鎖但沒加volatile多線程環(huán)境下指令重排序?qū)е履玫轿闯跏蓟甑膶?duì)象。解決如果對(duì)延遲加載沒有硬性要求直接用餓漢式類加載時(shí)就創(chuàng)建實(shí)例JVM 保證線程安全如果需要延遲加載用雙重檢查鎖加volatile或者用靜態(tài)內(nèi)部類方式利用 JVM 的類加載機(jī)制保證線程安全且實(shí)現(xiàn)延遲加載。最省事的是枚舉單例天然線程安全且防止反射攻擊。5.4 抽象工廠新增產(chǎn)品等級(jí)結(jié)構(gòu)時(shí)大面積改代碼現(xiàn)象原本只支持 User 和 Department 兩類對(duì)象的數(shù)據(jù)庫訪問層現(xiàn)在要加一個(gè) Score 對(duì)象結(jié)果抽象工廠接口、兩個(gè)具體工廠類、所有相關(guān)代碼都要改。原因抽象工廠模式的設(shè)計(jì)目標(biāo)是「增加產(chǎn)品族容易增加產(chǎn)品等級(jí)結(jié)構(gòu)困難」。產(chǎn)品族是橫向的SQL Server 族、Access 族產(chǎn)品等級(jí)結(jié)構(gòu)是縱向的User、Department、Score。縱向擴(kuò)展必然要改工廠接口。解決如果產(chǎn)品等級(jí)結(jié)構(gòu)經(jīng)常變化抽象工廠不是好選擇可以考慮用簡(jiǎn)單工廠配合反射或者改用工廠方法模式。如果產(chǎn)品等級(jí)結(jié)構(gòu)穩(wěn)定、產(chǎn)品族可能擴(kuò)展抽象工廠才是合適的。選型前先判斷哪個(gè)維度更可能變化。5.5 外觀模式把不該簡(jiǎn)化的接口也簡(jiǎn)化了現(xiàn)象為了「讓調(diào)用方便」寫了一個(gè)外觀類把子系統(tǒng)所有接口都包了一層結(jié)果子系統(tǒng)新增功能時(shí)外觀類也要跟著改而且有些調(diào)用方需要精細(xì)控制子系統(tǒng)外觀類反而成了障礙。原因外觀模式的定位是「為子系統(tǒng)提供一個(gè)簡(jiǎn)化的統(tǒng)一接口」它不應(yīng)該屏蔽子系統(tǒng)的所有能力只應(yīng)該封裝那些高頻、復(fù)雜的組合調(diào)用。解決外觀類只封裝最常用的幾組操作不要試圖覆蓋子系統(tǒng)的全部功能。需要精細(xì)控制的地方允許調(diào)用方直接訪問子系統(tǒng)。外觀模式的價(jià)值在于降低客戶端與子系統(tǒng)的耦合不是完全隔離。6. 驗(yàn)收與答辯用模擬試卷和對(duì)比表做一輪自檢復(fù)習(xí)到最后怎么判斷自己真的掌握了而不是「看過了」這份文檔給了一個(gè)很實(shí)用的收口方式練習(xí)題加模擬試卷。我的建議是把它當(dāng)成驗(yàn)收環(huán)節(jié)來用而不是當(dāng)額外的負(fù)擔(dān)。具體操作分三步走。第一步合上文檔拿一張白紙把七大設(shè)計(jì)原則和 23 種模式按創(chuàng)建型、結(jié)構(gòu)型、行為型三類默寫出來每個(gè)模式用一句話寫清楚「它解決什么問題」。寫不出來的就是沒記住的回去補(bǔ)。第二步打開文檔最后的對(duì)比表遮住結(jié)論部分自己先判斷每組模式的區(qū)別再對(duì)照文檔看說得對(duì)不對(duì)。比如「適配器 vs 裝飾器 vs 代理」這組你能不能準(zhǔn)確說出適配器改變接口、裝飾器增強(qiáng)功能、代理控制訪問說不清楚就回去看對(duì)應(yīng)章節(jié)。第三步做模擬試卷重點(diǎn)看錯(cuò)題涉及的是哪個(gè)模式、哪個(gè)原則針對(duì)性補(bǔ)漏。答辯場(chǎng)景下有幾個(gè)高頻問題值得提前準(zhǔn)備。一是「你這個(gè)項(xiàng)目里用了哪些設(shè)計(jì)模式為什么選它不選別的」——回答時(shí)一定要結(jié)合具體場(chǎng)景說清楚不用這個(gè)模式會(huì)有什么問題。二是「抽象工廠和工廠方法有什么區(qū)別」——抓住「一個(gè)產(chǎn)品族 vs 一個(gè)產(chǎn)品等級(jí)結(jié)構(gòu)」這個(gè)核心差異。三是「策略模式和狀態(tài)模式怎么區(qū)分」——用「客戶端主動(dòng)切換 vs 內(nèi)部狀態(tài)驅(qū)動(dòng)切換」來回答。四是「單例模式有哪些實(shí)現(xiàn)方式各自優(yōu)缺點(diǎn)是什么」——至少能說出餓漢式、雙重檢查鎖、靜態(tài)內(nèi)部類三種。我自己的習(xí)慣是每次復(fù)習(xí)完一個(gè)模式就找一個(gè)自己寫過的項(xiàng)目代碼看看能不能用這個(gè)模式重構(gòu)一小塊。能重構(gòu)成功說明真懂了重構(gòu)完發(fā)現(xiàn)更復(fù)雜了說明這個(gè)場(chǎng)景不適合用這個(gè)模式也是一種收獲。從那以后我每次準(zhǔn)備設(shè)計(jì)模式相關(guān)的答辯或評(píng)審都強(qiáng)制走一遍「默寫 → 對(duì)比 → 重構(gòu)」這三步比反復(fù)看文檔有效得多。希望這份拆解能幫你把設(shè)計(jì)模式復(fù)習(xí)從「背了忘、忘了背」的循環(huán)里拉出來真正變成一套能用在項(xiàng)目和答辯里的方案。完整文檔里還有剩余 15 種模式的詳細(xì)分析和更多實(shí)例代碼需要的話可以拿去對(duì)照著過一遍。本文還有配套的精品資源點(diǎn)擊獲取