《設計模式那點事》 - 書摘精要

(P03)

設計模式是實際經驗的積累和總結，着重解決具體的實際問題；

(P04)

在程序中要儘量使用抽象類型作爲對象實例變量類型，這樣就保證了將客戶程序與具體實現之間解耦，因爲使用的是抽象類型，因此具體實現的改變不會影響抽象類型的改變；

“對象組合” —— 是指在一個對象中含有另外一個對象的引用，從而可以使用該內部對象的引用作出一些處理行爲；

“開-閉原則”是一種很抽象的設計原則，更像是一種倡導的口號，其他設計原則都是爲了實現“開-閉原則”的具體原則；

(P5)

設計模式或將成爲改變一個人職場命運、一個企業成敗關鍵、甚至一個社會經濟發展的重要因素；

設計模式就像一本武功祕笈，要在學習中有所思、有所想、有所悟，才能達到軟件設計思想的最高境界；

(P5)

設計模式分類：

按照範圍來分，設計模式可以分爲“類模式”和“對象模式”：

“類模式” —— 用來處理類和子類之間的關係，這些關係通過繼承建立，是靜態的，在編譯時刻便確定下來了；

“對象模式” —— 是處理對象間的關係，這些關係在運行時是可以變化的，更具動態性；

按照目的來分，設計模式可以分爲“創建型模式”、“結構型模式”和“行爲型模式”：

“創建型模式” —— 用來處理對象的創建過程；

“結構型模式” —— 用來處理類或者對象的組合；

“行爲型模式” —— 用來對類或對象怎樣交互和怎樣分配職責進行描述；

按照目的的分類是採用最多的分類方式；

(P7)

讓理論指導實踐，實踐充實理論，這樣就會形成一種良性循環，不斷提升自己的理論、實踐能力；

(P49)

所謂“對象組合”，就是讓對象作爲類的成員變量，通過構造函數或者 set 方法給類對象的實例變量賦值；

一般“抽象工廠”和“工廠方法”都是聯合在一起使用，這樣的系統結構更加具有靈活性和彈性；

當設計一個軟件系統的時候，要儘可能地對系統中出現的各種事物進行抽象，從而建立基礎的抽象底層，這樣做的目的就是讓軟件結構更加框架化、系統化，系統結構更加靈活，易維護、易擴展；

(P50)

抽象和具體實現的區別就在於：有了抽象，能做很多事情，並且新增功能不會對原系統的穩定性造成影響，系統更加模塊化，軟件更加易複用；而具體實現只能完成一件事情，並且新增功能對原系統影響比較大，對於相同結構軟件不能複用，大大降低了開發效率，而且程序不易擴展；

(P51)

“工廠方法模式”和“抽象工廠模式”的區別：

“工廠方法模式”通過繼承的方式實現應用程序的解耦，而“抽象工廠模式”則通過對象組合的方式實現程序解耦；

“工廠方法模式”用來創建一個抽象產品，具體工廠實現工廠方法來創建具體產品，而“抽象工廠模式”用來創建一個產品家族的抽象類型；

(P72)

“建造者模式”和“抽象工廠模式”的區別：

“建造者模式”着重於分步驟構造一個複雜對象；“抽象工廠模式”着重於多個系列的產品對象的構造；

“建造者模式”是在最後一步返回具體產品；“抽象工廠模式”是立即返回具體產品；

(P81)

在 Java 中，只有實現了 Cloneable 接口的類纔會被虛擬機認爲是能夠克隆的；

(P129)

類適配器和對象適配器是外部對象和適配器的一種關聯關係，類適配器使用繼承方式，它是一種強關聯關係，而對象適配器是利用組合的方式，將外部對象傳入，它是一種弱關聯關係；

(P133)

適配器設計模式主要用於系統的升級擴展，或者版本兼容性上，沒有哪一個系統分析師會在軟件設計階段使用適配器模式的。適配器模式可以很好地解決版本兼容問題；

(P139)

“耦合” —— 就是兩個實體的行爲的某種強關聯；

“脫耦” —— 將它們的強關聯去掉，就是耦合的解脫，或稱脫耦；

橋接模式中的脫耦，就是指在一個軟件系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使兩者可以相對獨立地變化；

(P147)

橋接模式的魅力就在於將抽象和實現解耦，從而使兩者可以相對獨立地變化，而互不影響；

(P155)

軟件設計模式的初衷就是爲了解決軟件複用、內聚、耦合等問題。在類與類之間，應該儘量使用弱關聯的關係，如果兩個類的關係確實非常緊密，則使用繼承的強類型關係。一般情況下，要儘量避免使用高耦合度的設計方式；

(P156)

繼承是一種牢不可分的強關聯關係，而聚合的委託關係則是一種弱關聯關係，後者有利於類之間的解耦；

(P182)

組合模式，主要處理樹形結構以表示“部分-整體”的層次結構；

(P206)

設計模式是封裝變化的最好闡釋，無論哪一種設計模式針對的都是軟件系統中存在“變化”的部分，然後使用抽象對這些“變化”的部分進行封裝；

(P223)

外觀沒有封裝子系統的類，只提供簡化的接口；

(P381)

在一個軟件項目的設計中，一般不建議採用中介者模式；

(P463)

抽象類應當擁有儘可能多的行爲，應當擁有儘可能少的數據；

(P499)

訪問者模式適用於數據結構相對穩定算法又易變化的系統，因爲訪問者模式使得算法操作增加變得容易。如果系統數據結構對象易於變化，經常有新的數據對象增加進來，則不適合使用訪問者模式；

(P509)

“開-閉”原則告訴我們，一個軟件實體對於外部的需求變化，應該通過擴展來實現，而不是修改現有的內容來實現；

(P510)

在設計一個軟件系統結構時，儘可能地將會發生變化的內容獨立出來，單獨進行封裝，而將這一部分作爲抽象爲其他部分調用；

(P528)

依賴倒置原則是實現“開-閉”原則的重要途徑，在程序中要儘量使用抽象類型作爲對象實例變量類型，這樣就保證了將客戶程序與具體實現之間解耦；

(P536)

依賴倒置原則的核心是依賴抽象編程，而不依賴具體實現類；

接口屬於客戶，不屬於它所在的類層次結構；

(P544)

在實際的軟件設計中需要面向抽象編程，在程序中使用抽象類型作爲參數類型，然後將具體的子類型作爲實際運行的參數傳入，實現具體的行爲處理；

(P545)

迪米特法則實現要點是：儘量不要讓類和類之間建立直接的關係，如果需要建立關係，最好通過其友元類來中轉建立關係；