一、文章來由

按照慣例，來一個來由，這是《設計模式—可復用面向對象軟件的基礎》的讀書筆記，整理給自己看的，整理的內容也會不斷更新。大神輕噴~~如果不喜歡請留言說明原因再踩哦，謝謝，我也可以知道原因，不斷進步

二、讀書筆記

1、P12 可復用的面向對象設計的原則：

（1）針對接口編程，而不是針對實現編程。不將變量聲明為某個特定的具體類的實例對象，而是讓它遵從抽象類所定義的接口；
（2）優先使用對象組合，而不是類繼承。理想情況下，你不應為獲得復用而去創建新的構件。你應該能夠只使用對象組合技術，通過組裝已有的構件就能獲得你需要的功能。但是事實很少如此，因為可用構件的集合實際上并不足夠豐富。使用繼承的復用使得創建新的構件要比組裝舊的構件來得容易。這樣，繼承和對象組合常一起使用。

2、P14 委托

委托(delegation)是一種組合方法，它使組合具有與繼承同樣的復用能力。舉例來說，我們可以在窗口類中保存一個矩形類的實例變量來代理矩形類的特定操作，這樣窗口類可以復用矩形類的操作，而不必像繼承時那樣定義成矩形類的子類。也就是說，一個窗口擁有一個矩形，而不是一個窗口就是一個矩形。窗口現在必須顯式的將請求轉發給它的矩形實例，而不是像以前它必須繼承矩形的操作。

3、三種復用機制：

（1）繼承和組合（繼承是編譯時靜態定義，組合可在運行時確定）
（2）委托
（3）參數化類型，即template

4、P20 設計模式所支持的設計的可變方面

設計模式允許你獨立變化的方面，你可以改變它們而又不會導致重新設計。

5、P33 工廠類和產品類

這里用到了多態，我在我的另一篇博文里面也提到過

6、P37 對變化的概念進行封裝

在一給定平臺上建立 Lexi 時，我們選擇一個相應的版本。但想象一下，維護問題實在令人頭
疼，我們已經保存了多個名字都是“Window”的類，而每一個類實現于一個不同的窗口系統。
另一種方法是為每一個窗口層次結構中類創建特定實現的子類，但這會產生我們在試圖增加
修飾時遇到的同樣的子類數目爆炸問題。這兩種方法還都有另一個缺點：我們沒有在編譯以
后改變所用窗口系統的靈活性。所以我們還不得不保持若干不同的可執行程序。

既然這兩種方法都沒有吸引力，那么我們還能做些什么呢？那就是我們在格式化和修飾
時都做過的：對變化的概念進行封裝。現在所變化的是窗口系統實現。如果我們能在一個對象中封裝窗口系統的功能，那么我們就能根據對象接口實現 Window 類及其子類。更進一步講，如果那個接口能夠提供我們所感興趣的所有窗口系統的服務，那么我們無需改變 Window 類或其子類，也能支持不同的窗口系統。我們可以通過簡單傳遞合適的窗口系統封裝對象，來給我們想要的窗口系統設定窗口對象。我們甚至能在運行時刻設定窗口。

這個總結一下就是：因為變化的地方是不確定的，可能會外包給很多人去寫，所以要有一個統一的、穩定的接口，其他的封裝成不同類。

7、P40 Bridge模式

總結

以上是生活随笔為你收集整理的设计模式---读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。