一、文章來由

按照慣例，來一個來由，這是《設(shè)計模式—可復(fù)用面向?qū)ο筌浖幕A(chǔ)》的讀書筆記，整理給自己看的，整理的內(nèi)容也會不斷更新。大神輕噴~~如果不喜歡請留言說明原因再踩哦，謝謝，我也可以知道原因，不斷進步

二、讀書筆記

1、P12 可復(fù)用的面向?qū)ο笤O(shè)計的原則：

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

2、P14 委托

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

3、三種復(fù)用機制：

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

4、P20 設(shè)計模式所支持的設(shè)計的可變方面

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

5、P33 工廠類和產(chǎn)品類

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

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

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

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

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

7、P40 Bridge模式

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。