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

(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)

迪米特法則實現要點是：儘可能不要讓類和類之間創建直接的關係，若是須要創建關係，最好經過其友元類來中轉創建關係；