簡(jiǎn)介王桂林撰寫的《設(shè)計(jì)模式》PDF文檔面向希望系統(tǒng)掌握設(shè)計(jì)模式的軟件開發(fā)者與在校學(xué)生。內(nèi)容從設(shè)計(jì)模式的歷史淵源講起介紹克里斯托弗·亞歷山大提出的模式語言以及GOF四位作者的經(jīng)典著作并系統(tǒng)講解模式名稱、問題、解決方案、效果與結(jié)構(gòu)等陳述要素隨后給出學(xué)習(xí)模式的意義與建議涵蓋GOF的實(shí)踐觀點(diǎn)和《Head First Design Patterns》等推薦書目。后半部分重點(diǎn)剖析單一職責(zé)、開閉、依賴倒置、接口隔離等核心原則結(jié)合問題由來與解決方案幫助讀者識(shí)別代碼壞味道并重構(gòu)出更易維護(hù)的軟件。資源為單個(gè)PDF文件大小3.09MB目錄結(jié)構(gòu)清晰適合按章循序閱讀或作為案頭參考。已有157人學(xué)習(xí)下載無論是初學(xué)者建立設(shè)計(jì)模式框架還是開發(fā)者復(fù)盤面向?qū)ο笤O(shè)計(jì)原則都能從中獲得實(shí)用指導(dǎo)。1. 設(shè)計(jì)模式到底是什么先看懂套路這個(gè)詞一說起設(shè)計(jì)模式很多剛開始寫代碼的人第一反應(yīng)是又是一堆畫滿箭頭的類圖。但設(shè)計(jì)模式并不是讓你背圖的考試題。通俗地說設(shè)計(jì)模式是軟件行業(yè)里被無數(shù)前輩踩過坑之后總結(jié)出的套路就像廚師做菜時(shí)的下鍋順序和調(diào)味節(jié)奏每種經(jīng)典菜式都有被反復(fù)驗(yàn)證的做法。它提供的是遇到某種情境、碰到某類問題可以用某種標(biāo)準(zhǔn)解法的經(jīng)驗(yàn)而不是一段可以直接復(fù)制的代碼?？炊鼊e人寫的類就不再是一團(tuán)亂麻而是能叫出名字的協(xié)作結(jié)構(gòu)你自己寫代碼時(shí)也能少走很多彎路這就是這份資料想讓你搞明白的第一件事。2. 為什么需要設(shè)計(jì)模式六大原則回答怎么寫才不壞2.1 單一職責(zé)原則一個(gè)類只管一件事先從一個(gè)最影響日常開發(fā)的原則說起。你有沒有見過這樣的類一個(gè)訂單類里既存數(shù)據(jù)庫、又算價(jià)格、還負(fù)責(zé)發(fā)通知郵件。功能全擠在一起看起來方便真到改需求的時(shí)候誰都不敢動(dòng)——改計(jì)價(jià)規(guī)則怕碰壞存庫邏輯調(diào)了通知模板又擔(dān)心影響下單流程。這就是職責(zé)過載。單一職責(zé)原則SRP的定義很直白一個(gè)類應(yīng)當(dāng)只有一個(gè)引起它變化的原因。換句話說一個(gè)類只負(fù)責(zé)干好一件完整的事。如果一件事有變化只影響這個(gè)類另一件事有變化不該牽連到它。問題由來很清楚多個(gè)職責(zé)耦合在同一個(gè)類里任何一個(gè)需求變動(dòng)都會(huì)波及整個(gè)類測(cè)試和回歸的成本跟著翻倍。解決方案也簡(jiǎn)單拆。把不同的職責(zé)分給不同的類再用組合把它們組織起來。# 反例一個(gè)類包辦了存儲(chǔ)、計(jì)價(jià)、通知三種職責(zé) class OrderService: def save(self, order): pass # 寫數(shù)據(jù)庫 def calc_total(self, order): pass # 計(jì)算訂單總價(jià) def send_email(self, order): pass # 發(fā)送通知拆完之后會(huì)有三個(gè)只承擔(dān)單一職責(zé)的類OrderRepository只管存取PriceCalculator只管算價(jià)MailNotifier只管通知。OrderService只負(fù)責(zé)按順序調(diào)用它們。這樣做的價(jià)值在于以后價(jià)格規(guī)則怎么改跟數(shù)據(jù)庫怎么存沒有關(guān)系郵件模板再折騰也不會(huì)影響訂單落庫。判斷一個(gè)類是否違反 SRP可以問自己一句這個(gè)類如果明天要?jiǎng)h掉一半代碼剩下的一半是否能說清它到底在干嘛2.2 開閉原則加功能不拆老房子開閉原則OCP是設(shè)計(jì)模式里被引用最多的一條軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開放、對(duì)修改關(guān)閉。聽起來繞其實(shí)一句話就能講透——要給系統(tǒng)加新功能時(shí)盡量通過增加新代碼來實(shí)現(xiàn)而不是回頭去改已經(jīng)穩(wěn)定運(yùn)行的老代碼。問題由來也很常見系統(tǒng)上線后需求不斷變今天支持支付寶明天支持微信后天又來銀聯(lián)。如果每加一種支付方式都要打開原來的支付處理類改一長串 if-else那么每改一次原本跑得好好的支付流程都有被改崩的風(fēng)險(xiǎn)。改老代碼本質(zhì)上是在用舊功能的安全換新功能的落地。解決方案是依賴抽象把不變的部分定成接口或父類把會(huì)變的部分交給子類去實(shí)現(xiàn)。class PayGateway: def pay(self, amount): raise NotImplementedError class Alipay(PayGateway): def pay(self, amount): print(f支付寶支付 {amount} 元) class WechatPay(PayGateway): def pay(self, amount): print(f微信支付 {amount} 元)主流程只需要認(rèn)識(shí) PayGateway 這個(gè)接口新增銀聯(lián)支付時(shí)新建一個(gè) UnionPay 類去實(shí)現(xiàn) pay 方法即可老代碼一行不動(dòng)。開閉原則并不是要求你永遠(yuǎn)不修改代碼而是告訴你當(dāng)變化頻繁發(fā)生、又總是落在同一處時(shí)就該考慮用接口把穩(wěn)定骨架和易變細(xì)節(jié)隔離開這才是它真正的價(jià)值。2.3 依賴倒置原則面向抽象編程依賴倒置原則DIP解決的是高層模塊和底層模塊誰說了算的問題。很多新人的代碼里業(yè)務(wù)層直接 new 了一個(gè) MySQL 連接類用到哪寫到哪。這在一開始沒毛病可一旦公司決定換 Oracle所有用過這個(gè)連接類的地方都要跟著改業(yè)務(wù)層被迫綁死在一個(gè)底層實(shí)現(xiàn)上。依賴倒置的意思是高層模塊不要直接依賴低層模塊兩層都要依賴抽象抽象不依賴細(xì)節(jié)細(xì)節(jié)要依賴抽象。用人話說你的業(yè)務(wù)代碼只認(rèn)存儲(chǔ)接口不認(rèn)某個(gè)具體的數(shù)據(jù)庫。class Storage: def save(self, data): raise NotImplementedError class MySQLStorage(Storage): def save(self, data): print(f寫入 MySQL: {data}) class UserService: def __init__(self, storage: Storage): self.storage storage # 依賴的是抽象不是某個(gè)具體數(shù)據(jù)庫上面的 UserService 只認(rèn) Storage 類型。想換成 Oracle就新建一個(gè) OracleStorage 類在創(chuàng)建 UserService 時(shí)傳入即可UserService 的代碼完全不用動(dòng)。依賴倒置和開閉原則經(jīng)常配合出現(xiàn)接口負(fù)責(zé)穩(wěn)定具體實(shí)現(xiàn)負(fù)責(zé)變化。這也是面向接口編程這句老話的底層邏輯。2.4 接口隔離與里氏替換兩個(gè)容易忽視的規(guī)矩接口隔離原則ISP說的是不要強(qiáng)迫調(diào)用方去依賴它根本用不上的方法。有人圖省事把十幾個(gè)方法塞進(jìn)一個(gè)萬能接口實(shí)現(xiàn)類為了通過編譯不得不把不用的方法也寫個(gè)空實(shí)現(xiàn)。正確的做法是把大接口拆成幾個(gè)小接口讓每個(gè)調(diào)用方只依賴它真正需要的那部分。里氏替換原則LSP則是關(guān)于繼承的任何用到父類的地方都應(yīng)該能用子類替換且不破壞系統(tǒng)行為。經(jīng)典反例是正方形繼承矩形——矩形有設(shè)置寬度和設(shè)置高度兩個(gè)操作到了正方形里為了保持四邊相等設(shè)置寬度時(shí)還得偷偷把高度也改了。結(jié)果就是把正方形當(dāng)成矩形使用時(shí)程序行為完全亂套。正方形和矩形各有各的長相正確的建模是讓它們都實(shí)現(xiàn)一個(gè) Shape 抽象而不是硬湊繼承關(guān)系。這六條原則一起回答了為什么需要設(shè)計(jì)模式它們保證代碼在需求不斷變化時(shí)仍然可維護(hù)、可擴(kuò)展、團(tuán)隊(duì)之間好溝通。后面的每一種模式本質(zhì)上都是這些原則的具象化。3. UML 類圖關(guān)系一眼分清六種連接方式3.1 從面向過程到面向?qū)ο箢悎D為什么存在早期程序員寫程序靠的是函數(shù)數(shù)據(jù)傳來傳去邏輯按步驟往下走代碼規(guī)模一大就變成面條代碼。面向?qū)ο蟪霈F(xiàn)后程序被拆成一個(gè)個(gè)對(duì)象對(duì)象之間靠發(fā)消息協(xié)作。既然對(duì)象要協(xié)作它們之間就會(huì)有各種連接方式UML 類圖就是用來把這些連接畫出來的語言。面向過程時(shí)代模塊之間最直接的聯(lián)系就是一個(gè)函數(shù)調(diào)用另一個(gè)函數(shù)到了面向?qū)ο髸r(shí)代類和類之間存在繼承、包含、使用等多種關(guān)系。類圖畫的是靜態(tài)結(jié)構(gòu)只看它能知道誰認(rèn)識(shí)誰誰擁有誰誰是誰的子類。王桂林講義第 3、4 章把關(guān)系分成縱向和橫向兩條線縱向是泛化和實(shí)現(xiàn)橫向是組合、聚合、關(guān)聯(lián)、依賴共六種。3.2 泛化和實(shí)現(xiàn)兩條繼承軸先把兩條縱向關(guān)系講清。泛化Generalization就是繼承表示 is-a 關(guān)系狗是一種動(dòng)物學(xué)生是一個(gè)人。類圖里用實(shí)線加空心三角箭頭箭頭指向父類。class Animal: def eat(self): print(進(jìn)食) class Dog(Animal): # 泛化Dog 繼承自 Animal def bark(self): print(汪汪)實(shí)現(xiàn)Realization表示一個(gè)類兌現(xiàn)了某個(gè)接口定義的契約。類圖里用虛線加空心三角箭頭箭頭指向接口。在 Python 中接口通常借助 abc 模塊模擬語義上跟 Java 的 interface 一致。class Speaker: def speak(self): raise NotImplementedError class Dog(Speaker): def speak(self): print(汪汪)區(qū)分這兩個(gè)關(guān)系有個(gè)很實(shí)用的判斷方式泛化是繼承已有代碼和身份是父子血緣實(shí)現(xiàn)是承諾完成一組約定動(dòng)作是履行合同。一個(gè)類可以繼承一個(gè)父類同時(shí)實(shí)現(xiàn)多個(gè)接口這在類圖里并不沖突。3.3 組合與聚合同生共死還是一別兩寬橫向關(guān)系里最容易搞混的就是組合Composition和聚合Aggregation。兩條都是整體包含部分的關(guān)系區(qū)別全在一個(gè)問題上部分能不能脫離整體獨(dú)立存活。聚合用空心菱形表示整體持有部分但部分有自己的生命周期。學(xué)校和老師就是典型的聚合學(xué)校解散了老師們依然存在可以再去別的學(xué)校。組合用實(shí)心菱形表示整體和部分同生共死。比如人和心臟心臟是人體的一部分人沒了心臟這個(gè)器官也就失去了意義。class Teacher: def __init__(self, name): self.name name class School: def __init__(self, teachers): self.teachers teachers # 聚合老師從外面?zhèn)魅肟瑟?dú)立存活 class Heart: pass class Person: def __init__(self): self.heart Heart() # 組合心臟隨 Person 創(chuàng)建同生共死判斷維度聚合空心菱形組合實(shí)心菱形生命周期部分可獨(dú)立于整體存活部分與整體同生共死創(chuàng)建方式整體創(chuàng)建前甚至可以不依賴部分整體創(chuàng)建時(shí)創(chuàng)建部分典型例子學(xué)校與老師、公司與員工人與心臟、訂單與訂單項(xiàng)一個(gè)口訣是聚合是拼裝組合是生長。拼裝的零件拆下來還能用生長的器官離開整體就失去意義。3.4 關(guān)聯(lián)與依賴兩條弱關(guān)系也別看輕再看另外兩種橫線。關(guān)聯(lián)Association用一條實(shí)線表示雙方都持有對(duì)方的引用彼此認(rèn)識(shí)?？蛻艉陀唵问顷P(guān)聯(lián)關(guān)系客戶知道自己的訂單訂單也指向所屬客戶它們互相引用誰也不是誰的附屬品。依賴Dependency是六種關(guān)系里最弱的一種用帶虛線的箭頭表示。它的特征是一個(gè)類的方法在運(yùn)行過程中臨時(shí)用到了另一個(gè)類這個(gè)類只出現(xiàn)在方法的局部變量、參數(shù)或返回值里并不作為字段保存。比如方法里臨時(shí)構(gòu)造了一個(gè)格式化工具來拼接字符串方法結(jié)束聯(lián)系結(jié)束。六種關(guān)系按強(qiáng)度排個(gè)序泛化和實(shí)現(xiàn)屬于繼承軸是血緣關(guān)系組合強(qiáng)于聚合聚合強(qiáng)于關(guān)聯(lián)關(guān)聯(lián)強(qiáng)于依賴。在類圖里認(rèn)關(guān)系有個(gè)小技巧先找空心三角箭頭繼承/實(shí)現(xiàn)再找菱形組合/聚合剩下沒有菱形的實(shí)線是關(guān)聯(lián)帶虛線的箭頭是依賴。這六種關(guān)系掌握之后看任何一份設(shè)計(jì)模式的類圖你都不會(huì)再發(fā)怵。4. 易混概念設(shè)計(jì)模式學(xué)習(xí)中最容易翻車的五個(gè)誤區(qū)4.1 誤區(qū)一設(shè)計(jì)模式就是代碼模板容易把設(shè)計(jì)模式當(dāng)模板背是因?yàn)榫W(wǎng)上的示例代碼都長得很像給人一種抄下來就能用的錯(cuò)覺。但模式的核心從來不是那幾行代碼而是在什么情境下、遇到什么問題、采用什么解法。同一個(gè)單例在 Java、Python、C 里的寫法各不相同可模式思想完全一致。只背代碼而不理解適用場(chǎng)景換一種語言或換一個(gè)項(xiàng)目代碼根本套不進(jìn)去。怎么區(qū)分先問自己這個(gè)模式解決的是什么問題答得上來才算真正認(rèn)識(shí)它。4.2 誤區(qū)二設(shè)計(jì)模式和算法是一回事兩者都給出步驟和結(jié)構(gòu)確實(shí)容易混。但算法解決的是怎么算排序、查找、哈希關(guān)心的是計(jì)算過程和復(fù)雜度設(shè)計(jì)模式解決的是怎么組織代碼類和對(duì)象怎么劃分、怎么協(xié)作、怎么應(yīng)對(duì)變化。算法是零件模式是裝配方案。策略模式就可以把排序算法封裝成一個(gè)策略對(duì)象運(yùn)行時(shí)替換但你能說排序是設(shè)計(jì)模式嗎顯然不能。4.3 誤區(qū)三組合和聚合分不清這個(gè)誤區(qū)在第 3 章詳細(xì)講過這里再濃縮成兩句話。組合是心臟和人體的關(guān)系——整體沒了部分也沒意義聚合是老師和學(xué)校的關(guān)系——學(xué)校沒了老師依然活著。判斷標(biāo)準(zhǔn)只有一條看部分能不能脫離整體獨(dú)立存活。畫類圖時(shí)先看菱形是實(shí)心還是空心實(shí)心是組合空心是聚合看一眼箭頭和菱形就夠。4.4 誤區(qū)四單例模式就是全局變量單例的確提供全局訪問點(diǎn)看起來和全局變量一樣隨手一拿就能用但本質(zhì)不同。全局變量是一個(gè)公開的名字誰都能重新賦值任何一處改了都會(huì)影響所有使用者風(fēng)險(xiǎn)完全失控。單例則限制了一個(gè)類只能有一個(gè)實(shí)例并把這個(gè)唯一實(shí)例的創(chuàng)建時(shí)機(jī)、訪問入口都管理起來。不過它也有自己的隱患所有調(diào)用方共享同一個(gè)可變狀態(tài)本質(zhì)上仍然是全局狀態(tài)。能用參數(shù)傳遞解決的問題就不必急著上單例。4.5 誤區(qū)五代理模式和裝飾模式長得像這兩個(gè)模式在類圖里都是包一個(gè)對(duì)象、實(shí)現(xiàn)同一個(gè)接口第一次接觸很容易看成同一個(gè)東西。區(qū)分的關(guān)鍵在意圖。代理模式的目的是控制對(duì)原對(duì)象的訪問——做權(quán)限校驗(yàn)、延遲加載、記錄訪問日志它像經(jīng)紀(jì)人或替身核心是把關(guān)。裝飾模式的目的是給對(duì)象動(dòng)態(tài)增加功能——加緩存、加日志、加格式轉(zhuǎn)換它像給奶茶加料核心是增強(qiáng)。一個(gè)管進(jìn)門一個(gè)管能力方向完全不同。這五個(gè)誤區(qū)覆蓋了初學(xué)者最容易摔跤的地方把模式當(dāng)模板、把模式當(dāng)算法、混淆關(guān)系、錯(cuò)用全局思想、張冠李戴結(jié)構(gòu)相似的模式。帶著這些區(qū)分再去學(xué)具體模式會(huì)順暢很多。5. 五個(gè)出場(chǎng)率最高的模式先學(xué)會(huì)用這幾個(gè)5.1 單例全局唯一的一份單例模式確保一個(gè)類只有一個(gè)實(shí)例并提供一個(gè)全局訪問點(diǎn)。最典型的應(yīng)用是全局配置文件整個(gè)系統(tǒng)只需要一份配置數(shù)據(jù)任何模塊讀取的都是同一份改配置時(shí)也只需要改一處。游戲引擎里的導(dǎo)演類、項(xiàng)目管理器、日志模塊用的都是單例。實(shí)現(xiàn)方式里延遲創(chuàng)建懶漢式是常見寫法第一次訪問實(shí)例時(shí)才真正創(chuàng)建。class Config: _instance None def __new__(cls, *args, **kwargs): if cls._instance is None: cls._instance super().__new__(cls) return cls._instance這段代碼有個(gè)需要注意的地方在多線程環(huán)境下兩個(gè)線程可能同時(shí)發(fā)現(xiàn) _instance 是 None然后各自創(chuàng)建出實(shí)例單例就失效了。解決方案是加鎖或者用雙重檢查鎖定——先判斷一次再加鎖鎖內(nèi)再判斷一次。參數(shù)說明_instance 是類級(jí)變量所有實(shí)例共享這正是它保證唯一性的關(guān)鍵。理解單例要同時(shí)看到它的兩面提供了統(tǒng)一入口也引入了共享狀態(tài)用不用它取決于系統(tǒng)是不是真的需要唯一。5.2 觀察者一呼百應(yīng)的發(fā)布訂閱觀察者模式解決的是一對(duì)多通知的問題。被觀察對(duì)象狀態(tài)變化時(shí)自動(dòng)通知所有注冊(cè)過的觀察者雙方互不綁死。公眾號(hào)推送文章、UI 按鈕監(jiān)聽點(diǎn)擊、游戲引擎里的事件系統(tǒng)都是觀察者的應(yīng)用。它之所以好用是因?yàn)楸挥^察者根本不需要知道觀察者具體是誰只要知道它們都實(shí)現(xiàn)了同一個(gè) update 接口。class Subject: def __init__(self): self._observers [] def attach(self, observer): self._observers.append(observer) def notify(self, message): for observer in self._observers: observer.update(message)Subject 維護(hù)一個(gè)觀察者列表notify 方法負(fù)責(zé)遍歷并通知。未來新增一個(gè)觀察者類只要實(shí)現(xiàn) update 方法就能接入Subject 的代碼完全不用改。這就是解耦的價(jià)值新功能以增加的方式加入系統(tǒng)而不是以修改的方式侵入系統(tǒng)。5.3 策略把算法抽出來換著用策略模式把一族算法分別封裝起來讓它們?cè)谶\(yùn)行時(shí)可以互相替換。遇到支付方式、價(jià)格計(jì)算、排序規(guī)則這類行為有多種方案的場(chǎng)景它是消滅 if-else 連招的有力工具。不用策略時(shí)代碼長這樣def calc(type, a, b): if type add: return a b elif type mul: return a * b這種寫法每來一種新規(guī)則就要改一次 calc 函數(shù)改著改著函數(shù)越來越長、越來越難維護(hù)。用策略模式重構(gòu)后每種算法獨(dú)立成一個(gè)類class AddStrategy: def execute(self, a, b): return a b class MultiplyStrategy: def execute(self, a, b): return a * b主流程只面向策略接口調(diào)用 execute新增平方、取余之類的規(guī)則時(shí)新建一個(gè)類就行主流程一行不改。這正是開閉原則的落地?cái)U(kuò)展靠新增類不靠改動(dòng)老代碼。5.4 代理替身演員兼經(jīng)紀(jì)人代理模式提供一個(gè)替身對(duì)象來控制對(duì)真實(shí)對(duì)象的訪問。三種最常見的形態(tài)虛代理負(fù)責(zé)延遲加載比如圖片瀏覽列表里先顯示占位滾動(dòng)到某張圖時(shí)才真正加載大圖智能代理負(fù)責(zé)在訪問前后做附加操作比如記錄調(diào)用次數(shù)、緩存結(jié)果保護(hù)代理負(fù)責(zé)權(quán)限校驗(yàn)先確認(rèn)調(diào)用者有權(quán)限才放行。class Image: def __init__(self, path): self._path path self._load_image() def display(self): print(顯示圖片:, self._path) class ImageProxy(Image): def __init__(self, path): self._real None self._path path def display(self): if self._real is None: self._real Image(self._path) # 真正需要時(shí)才加載大圖 self._real.display()ImageProxy 和真實(shí)圖片實(shí)現(xiàn)同一接口調(diào)用方感知不到代理的存在。大圖加載被推遲到第一次 display 時(shí)這就是虛代理的核心思路。參數(shù)說明_real 字段保存真實(shí)對(duì)象第一次訪問時(shí)為 None觸發(fā)加載后復(fù)用同一個(gè)對(duì)象避免重復(fù)創(chuàng)建。記住代理的目的是控制訪問不是增強(qiáng)功能——后者要找裝飾模式。5.5 裝飾一層一層往上疊裝飾模式給對(duì)象動(dòng)態(tài)添加職責(zé)比繼承更靈活。拿奶茶舉例一杯原味奶茶 10 元加珍珠加 3 元加椰果加 2 元加奶蓋加 4 元。如果用繼承去寫十種配料要組合出上百個(gè)類類直接爆炸用裝飾模式每種配料包一層就行。class MilkTea: def cost(self): return 10 class PearlDecorator: def __init__(self, base): self._base base def cost(self): return self._base.cost() 3 class CoconutDecorator: def __init__(self, base): self._base base def cost(self): return self._base.cost() 2要一杯珍珠椰果奶茶就從內(nèi)到外套兩層CoconutDecorator(PearlDecorator(MilkTea()))調(diào)用 cost 時(shí)一層層累加總共 15 元。裝飾器保持了原對(duì)象的接口調(diào)用方拿到的仍然是奶茶但能力被疊加上去。與繼承相比裝飾模式的優(yōu)勢(shì)是自由組合和按需添加不會(huì)產(chǎn)生類數(shù)量的組合爆炸。這五個(gè)模式中單例管唯一觀察者管通知策略管替換算法代理管控制訪問裝飾管動(dòng)態(tài)增強(qiáng)。它們是最常用也最好入門的五個(gè)把類圖和適用場(chǎng)景配合著看會(huì)比孤立記代碼有效得多。6. 設(shè)計(jì)模式什么時(shí)候用、什么時(shí)候別用邊界判斷6.1 什么時(shí)候該用判斷標(biāo)準(zhǔn)可以凝成三個(gè)信號(hào)第一代碼里出現(xiàn)大量重復(fù)結(jié)構(gòu)兩個(gè)類長得幾乎一樣只有局部行為不同第二某個(gè)功能頻繁變化每次變動(dòng)都要修改多處老代碼第三團(tuán)隊(duì)成員討論設(shè)計(jì)時(shí)靠你懂的交流結(jié)構(gòu)說不清楚。出現(xiàn)這些信號(hào)就該停下來畫一張類圖問自己這個(gè)變化的點(diǎn)能不能抽象出來用哪個(gè)原則能讓我少改老代碼這比悶頭繼續(xù)堆代碼有效率得多。6.2 什么時(shí)候別用反過來設(shè)計(jì)模式不是越多越好。一個(gè)需求明確、短期內(nèi)不會(huì)變的小腳本硬套上策略模式只會(huì)讓接手的同事繞路。團(tuán)隊(duì)里多數(shù)人還不熟悉某個(gè)模式時(shí)用它帶來的溝通成本可能超過收益。判斷標(biāo)準(zhǔn)很簡(jiǎn)單模式引入的間接層到底是在幫你隔離變化還是在單純?cè)黾哟a跳轉(zhuǎn)。如果答案偏向后者就別用。模式是解決問題的工具不是裝飾代碼的飾品。就拿我自己的經(jīng)歷來說有段時(shí)間我為了顯得專業(yè)把一段不到百行的工具腳本硬套上策略模式結(jié)果看代碼的人找了三個(gè)文件才搞懂入口在哪直接被罵了一頓。從那以后我每次接手復(fù)雜模塊都強(qiáng)制走一遍先畫類圖、再對(duì)六大原則、最后選模式的流程先搞清楚變化是什么再?zèng)Q定要不要引入設(shè)計(jì)模式。這套方法是這份講義最想傳達(dá)的東西模式不是背出來的是問題和情境一步步逼出來的。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取