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