設計模式的藝術

設計模式讀後感: 一: 這應該算是我看的第四本設計模式的書了，我在2017年購買了經典之作“設計模式—可複用面向對象軟件的基礎”（GOF設計模式），記憶猶新，學術性太強，當初啃得非常痛苦，沒有啃完，接着當然就是壓箱底了．隨着時間推移，在疫情期間，我選擇了程傑所著的《大話設計模式》，這本書以其輕鬆的語言風格給我留下了深刻印象，每個模式的概念都能輕易理解，然而在合上書後，由於缺乏實踐支撐以及對整體框架的系統性認識，這些模式在我腦海中尚未形成有機聯繫．後來，我投入兩個月時間研讀了厚達600多頁的《Head First 設計模式》，也在日常工作中，強迫並促使自己積極踐行設計模式的原則。至前年重讀GOF的著作時，對其內容的理解和閱讀體驗變得流暢了許多。 二: 在2024年，我開始使用微信讀書，機緣巧合的向我推薦了劉偉教授所著的《設計模式的藝術》一書，該書備受網友推崇，被譽爲“神作”。劉老師加了簡單工廠模式進來，總共就有２４種設計模式了．我決定每天抽出一點時間專注一種模式，並在三月份期間逐步完成了全書的閱讀。接下來，我分享一下此次閱讀後的心得體會。 １：加深了我對常見UML的用法，以前用的可能並不是很規範 ２：在閱讀過程中，挺喜歡劉老師這種清晰的教學方式，善於從具體的需求出發，先展示一種常見的、看似合理的實現方法，繼而揭示其中存在的問題，從而引出設計模式的必要性。通過這種逐步引導，讓我更加深刻地理解了每一個模式的價值所在，包括它們的不同應用場景、優缺點以及多種變形應用 ３：在這次研讀的過程中，我抱着每日只閱讀一個模式的明確目標，心態尤爲從容不迫。劉老師在書中精心設置的思考題與練習題目，我都一一付諸了實踐，讓我感受深刻的是，理論轉化爲實踐時，會面臨許多意想不到的新挑戰，但是在實踐的過程中，也會湧現出許多新穎的認識，特別是，各種模式間關聯性上的見解． ４：回顧四本設計模式書籍的學習歷程，如今面對需求或者問題時，就會下意識主動思考背後的業務背景，它的約束條件是什麼？要解決怎樣的問題？我們應該採用什麼方案？一旦選定某種設計方案，我便立即評估其潛在的效果，剖析方案的優點與不足之處．尤爲重要的是，我會將開閉原則作爲衡量設計方案質量的重要標尺，因爲我發現這一原則在日常工作實踐中起到了猶如通關密鑰的作用。倘若設計方案未能充分滿足開閉原則的要求，我便會繼續追問：是否有效地採用了面向接口編程手法？是否遵循了替換原則和依賴倒置原則？每個類的職責劃分是否足夠單一？封裝性是否得到了妥善處理？是否過度依賴繼承，而忽視了組合的優勢？對於調用者而言，接口設計是否友好易用？接口之間是否實現了必要的隔離？此外，類之間是否是松耦合？是否避免了不必要的大量交互？以及是否遵循了迪米特法則以降低耦合度。 ５：對於書中提到的設計模式乃“心法”之論，我個人的理解略有不同。我認爲設計原則纔是支撐起整個設計思維體系的心法，而23種設計模式則是依據這些原則演化出來的實戰招式。遵循設計原則的設計方案，無論最終呈現出何種形態，實質上都能找到與設計模式的內在聯繫，它們或是某一模式的標準形式，或是某種模式的變異形態，均指向了一種更爲合理且易於維護的設計架構。

終於碰到一本比較容易讀下去的設計模式書籍，說說本書的幾個優點： 1）每種設計模式都標有 學習難度&使用頻率 星星等級(這個太重要了)，讓我可以毫無心裏負擔的先去挑讀某些章節； 2）每種設計模式都配一個很生動的生活化的場景示例和一個擴展的源碼場景示例，讓你一下子對該種設計模式有一個體感； 3）有應用場景的簡潔的UML結構圖。 結合自己開發過程中，從最高頻的幾個設計模式開始挑讀，建立閱讀信心！ 1）. 創建型模式 6種 1. 單例模式 （高頻）：確保一個類只有一個實例，並提供一個全局訪問點來訪問這個唯一實例。 2. 工廠方法模式（高頻）：定義一個用於創建對象的接口，但是讓子類決定將哪一個類實例化。工廠方法模式讓一個類的實例化延遲到其子類。 3. 抽象工廠模式（高頻）：提供一個創建一系列相關或相互依賴對象的接口，而無須指定它們具體的類。 4. 簡單工廠模式（中頻）：定義一個工廠類，它可以根據參數的不同返回不同類的實例，被創建的實例通常都具有共同的父類。 5. 原型模式（中頻）：使用原型實例指定待創建對象的類型，並且通過複製這個原型來創建新的對象。 6. 建造者模式（低頻）：將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。 2）. 結構型模式 7種 1. 外觀模式（高頻）：爲子系統中的一組接口提供一個統一的入口。外觀模式定義了一個高層接口，這個接口使得子系統更加容易使用。 2. 適配器模式（高頻）：將一個類的接口轉換成客戶希望的另一個接口。適配器模式讓那些接口不兼容的類可以一起工作。 3. 組合模式（高頻）：組合多個對象形成樹形結構以表示具有部分-整體關係的層次結構。組合模式讓客戶端可以統一對待單個對象和組合對象。 4. 代理模式（高頻）：給某一個對象提供一個代理或佔位符，並由代理對象來控制對原對象的訪問。 5. 裝飾模式（中頻）：動態地給一個對象增加一些額外的職責。就擴展功能而言，裝飾模式提供了一種比使用子類更加靈活的替代方案。 6. 橋接模式（中頻）：將抽象部分與它的實現部分解耦，使得兩者都能夠獨立變化。 7. 享元模式（低頻）：運用共享技術有效地支持大量細粒度對象的複用。 3）. 行爲型模式 11種 1. 迭代器模式（高頻）：提供一種方法順序訪問一個聚合對象中各個元素，而又不用暴露該對象的內部表示。 2. 觀察者模式（高頻）：定義對象之間的一種一對多依賴關係，使得每當一個對象狀態發生改變時，其相關依賴對象皆得到通知並被自動更新。 3. 策略模式（高頻）：定義一系列算法，將每一個算法封裝起來，並讓它們可以相互替換。策略模式讓算法可以獨立於使用它的客戶而變化。 4. 命令模式（高頻）：將一個請求封裝爲一個對象，從而讓你可用不同的請求對客戶進行參數化，對請求排隊或者記錄請求日誌，以及支持可撤銷的操作。 5. 模版方法模式（中頻）：定義一個操作中算法的框架，而將一些步驟延遲到子類中。模板方法模式使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。 6. 狀態模式（中頻）：允許一個對象在其內部狀態改變時改變它的行爲。對象看起來似乎修改了它的類。 7. 責任鏈模式（低頻）：避免將一個請求的發送者與接收者耦合在一起，讓多個對象都有機會處理請求。將接收請求的對象連接成一條鏈，並且沿着這條鏈傳遞請求，直到有一個對象能夠處理它爲止。 8. 中介者模式（低頻）：定義一個對象來封裝一系列對象的交互。中介者模式使各對象之間不需要顯式地相互引用，從而使其耦合鬆散，而且讓你可以獨立地改變它們之間的交互。 9. 備忘錄模式（低頻）：在不破壞封裝的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態，這樣可以在以後將對象恢復到原先保存的狀態。 10. 訪問者模式（低頻）：表示一個作用於某對象結構中的各個元素的操作。訪問者模式可以在不改變各元素的類的前提下定義作用於這些元素的新操作。 11. 解釋器模式（低頻）：給定一個語言，定義它的文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。

基於面向對象編程的26種設計模式的案例性詳解，對於有一定編程經驗積累的讀者，應該會很有幫助。這個前提，也就意味着如果沒有相關經驗，那可能讀起來就比較痛苦，甚至難以形成直觀理解。 不過，所有這26種模式，在實際的軟件工程或者項目管理中，往往不是如書中那樣條理分明，界限清晰的。反而是在日常系統維護和更新時，需要快速解決問題時，大家會本能地採用一些已經非常熟練的套路。而這些套路往往就是這些模式中的一種或者幾種的組合。 但從我個人的經歷看，如果能從項目起始階段，就有意識地以這種模式化的思考，對項目需求和功能進行梳理定義，效果肯定會好很多。但這也往往意味着前期要投入更多時間和資源，與大量準備工作。這些工作相比於同期可見可量化的可交付成果而言，肯定是不成比例的。所以，最終就是在骨感的現實中，繼續用那些模式小技巧去打補丁，纔是最常見的日常。但即便如此，這本設計模式的速查手冊，也非常值得反覆閱讀。

本書涵蓋了所有的設計模式，講得通俗易懂，每個模式都給舉了不同的例子來給大家進行描述，並講解每個設計模式的原理以及代碼，每篇最後還附有設計模式的優點和缺點以及使用場景，還有一些思考問題和例題來供我們思考，發散思維。

每種設計模式以一個實際問題場景的描述，非最佳設計出發進行分析，然後再給出最佳設計模式的對應，從基礎的設計模式到該模式優化過程，整體層層遞進，讀起來還是挺舒服的。 落到實際開發過程中對具體問題分析抽象的能力，還需要自己動手繪製UML框圖揣摩、體會

簡單、易懂、真誠，是一本好書。看得出來作者喜歡金庸武俠，而喜歡金庸武俠的，我想都不會太壞。裏面有很多UML都畫得挺用心，代碼詳略得當。看完書才發現，竟然有60+w字，但讀下來主觀上感覺好像只有20w字，這大概是“讀起來不枯燥”最好的佐證（很多設計模式的書，翻開沒看幾秒就不想看了）。 這裏沒有批評其他書的意思，但市面上很多技術書，爲了講故事而講故事，反而把設計模式講得更糟糕，還不如直接開門見山談模式本身，輔以實際案例。

非常一般，看似專業詳細，其實是囉裏吧嗦抓不住精髓

需要耐心閱讀，帶着問題收穫很大。

劉偉的《設計模式的藝術》一書，主要講的是是23種設計模式。設計模式說的是“前人經驗的積累，它能讓軟件變得像一個藝術品，不再是一堆難以維護和重用的代碼”。 首先是以 創建對象爲目的的 5種常用的“創建型”設計模式： 確保系統中只有一個類的實例的-單例模式、 將對象的創建和對象的使用分離，集中式工廠體現-簡單工廠模式（它不屬於設計模式範疇）、 通過不同的工廠來創建不同類型對象的多態工廠的實現的-工廠方法模式、 能夠創建一系列產品（產品族）-抽象工廠模式、 通過克隆創建一個一模一樣的對象-原型模式、 複雜對象的組裝與創建的--建造者模式。 創建型模式中的 5中設計模式 能幫助我們 更好的管理對象的創建過程提高系統的靈活性、可擴展性、性能和可維護性。 接着是 以 組合爲目的的 的7種結構型的設計模式： 適配器模式：不兼容結構的協調，在不修改現有系統的前提下重用沒有原碼的第三方類庫； 橋接模式：避免在多層繼承結構中類的個數出現爆炸式增長，處理更多維度的變化； 組合模式：用面向對象的方式來處理軟件系統中的樹形結構； 裝飾模式：不通過繼承的方式，擴展了對象的功能； 外觀模式：爲複雜子系統提供一個統一的入口； 享元模式：實現對象的多次複用以節省系統的資源； 代理模式：對象之間的間接訪問； 結構型模式中 7種設計模式：更好的組合和管理系統（對象）的結構，降低耦合。目的也是提供系統的靈活性，可擴展性能，便於維護和開發。 最後是以交互爲目的的 行爲型的11種設計模式： 責任鏈模式：讓多個對象都有機會來處理同一個請求（請求的鏈式處理）； 命令模式：將請求的發送者和請求的接收者完全解耦； 解釋器模式：自定義一個語言的實現成爲可能； 迭代器模式：間接遍歷一個聚合對象中的元素； 中介者模式：協調多個對象之間的相互調用； 備忘錄模式：撤銷功能的實現； 觀察者模式：對象之間的聯動（一對多的聯動）； 狀態模式：設計和實現一個具有多個狀態的對象（狀態及其轉換）； 策略模式：算法的封裝與切換，在不修改現有代碼的情況下更換另一種算法； 模版方法模式：爲一個複雜算法的某些步驟提供多種實現方式，定義算法的框架； 訪問者模式：操作複雜對象的結構，運行一個或者多個操作應用到一組對象上，解耦操作和對象本身。 行爲型模式中的11種設計模式：更好的處理對象之間的交互和職責分配，也是提供系統的靈活性和擴展性，可維護性，可複用，效率，性能，可靠和安全。

懂的都懂，不懂的還是不懂，看了沒什麼長進（捂臉哭）