Where am I
目錄
00 引言
000 什么是設(shè)計模式？
每一個模式描述了一個在我們周圍不斷重復(fù)發(fā)生的問題， 以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重復(fù)勞動。
- 重復(fù)發(fā)生的問題
- 問題解決方案的核心
- 復(fù)用成熟的解決方案，減少重復(fù)的勞動
001 如何詳細描述某一設(shè)計模式？
| 描述角度 | 說明 |
|---|---|
| 意圖 | 通過什么方法解決什么樣的特定設(shè)計問題 |
| 別名 | 模式的其他名稱 |
| 動機 | 實現(xiàn)意圖的基礎(chǔ)、基本原理，說明一個模式中的類、對象如何解決特定的設(shè)計問題 |
| 適用性 | 什么情況下可以使用該設(shè)計模式？該設(shè)計模式可以用來改良哪些不良設(shè)計？我們怎樣識別這些情況？ |
| 參與者 | 指設(shè)計模式中的類或?qū)ο笠约八鼈兏髯缘穆氊?/td> |
| 協(xié)作 | 模式的參與者怎樣協(xié)作以實現(xiàn)它們的職責 |
| 結(jié)構(gòu) | 采用基于對象建模技術(shù)的表示法對模式中的類進行圖形描述 |
| 效果 | 模式怎樣支持它的目標？使用模式的效果和所需做的權(quán)衡取舍？系統(tǒng)結(jié)構(gòu)的哪些方面可以獨立改變？ |
| 實現(xiàn) | 實現(xiàn)模式時需要知道的一些提示、技術(shù)要點及應(yīng)避免的缺陷，以及是否存在某些特定于實現(xiàn)語言的問題 |
| 已知應(yīng)用 | 實際系統(tǒng)中發(fā)現(xiàn)的模式的例子。每個模式至少包括了兩個不同領(lǐng)域的實例 |
| 代碼示例 | 用來說明怎樣實現(xiàn)該模式的代碼片段 |
| 相關(guān)模式 | 與這個模式緊密相關(guān)的模式有哪些？其間重要的不同之處是什么？這個模式應(yīng)與哪些其他模式一起使用？ |
002 設(shè)計模式分類
分類準則
| 分類準則 | 類型 | 類型描述 |
|---|---|---|
| 目的 | 創(chuàng)建型 | 與對象的創(chuàng)建有關(guān) |
| 目的 | 結(jié)構(gòu)型 | 處理類或?qū)ο蟮慕M合 |
| 目的 | 行為型 | 對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊熯M行描述 |
| 范圍 | 類 | 處理類和子類之間的關(guān)系，這些關(guān)系通過繼承建立，是靜態(tài)的，在編譯時刻便確定下來了 |
| 范圍 | 對象 | 處理對象間的關(guān)系，這些關(guān)系在運行時刻是可以變化的，更具動態(tài)性 |
分類結(jié)果
| 類型名稱 | 類型描述 | 具體設(shè)計模式 | 設(shè)計模式描述 |
|---|---|---|---|
| 創(chuàng)建型類模式 | 將對象的部分創(chuàng)建工作延遲到子類 | ||
| 工廠方法模式 | 定義一個用于創(chuàng)建對象的接口，讓子類決定將哪一個類實例化 | ||
| 創(chuàng)建型對象模式 | 將對象的部分創(chuàng)建工作延遲到另一個對象 | ||
| 抽象工廠模式 | 提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類 | ||
| 建造者模式 | 將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示 | ||
| 原型模式 | 用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這個原型來創(chuàng)建新的對象 | ||
| 單例模式 | 保證一個類僅有一個實例，并提供一個訪問它的全局訪問點 | ||
| 結(jié)構(gòu)型類模式 | 使用繼承機制來組合類 | ||
| 適配器模式（類） | 將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作 | ||
| 結(jié)構(gòu)型對象模式 | 描述了對象的組裝方式 | ||
| 適配器模式（對象） | 將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作 | ||
| 橋接模式 | 將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立地變化 | ||
| 組合模式 | 將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。Composite使得客戶對單個對象和復(fù)合對象的使用具有一致性 | ||
| 裝飾器模式 | 動態(tài)地給一個對象添加一些額外的職責。就擴展功能而言，Decorator模式比生成子類方式更為靈活 | ||
| 外觀模式 | 為子系統(tǒng)中的一組接口提供一個一致的界面，F(xiàn)acade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用 | ||
| 享元模式 | 運用共享技術(shù)有效地支持大量細粒度的對象 | ||
| 代理模式 | 為其他對象提供一個代理以控制對這個對象的訪問 | ||
| 類行為型 | 使用繼承描述算法和控制流 | ||
| 解釋器模式 | 給定一個語言,定義它的文法的一種表示，并定義一個解釋器,該解釋器使用該表示來解釋語言中的句子 | ||
| 模板方法模式 | 定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。TemplateMethod使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟 | ||
| 對象行為型 | 描述一組對象怎樣協(xié)作完成單個對象所無法完成的任務(wù) | ||
| 職責鏈模式 | 為解除請求的發(fā)送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它 | ||
| 命令模式 | 將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數(shù)化;對請求排隊或記錄請求日志，以及支持可取消的操作 | ||
| 迭代器模式 | 提供一種方法順序訪問一個聚合對象中各個元素,而又不需暴露該對象的內(nèi)部表示 | ||
| 中介者模式 | 用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互 | ||
| 備忘錄模式 | 在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復(fù)到保存的狀態(tài) | ||
| 觀察者模式 | 定義對象間的一種一對多的依賴關(guān)系,以便當一個對象的狀態(tài)發(fā)生改變時,所有依賴于它的對象都得到通知并自動刷新 | ||
| 狀態(tài)模式 | 允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為。對象看起來似乎修改了它所屬的類 | ||
| 策略模式 | 定義一系列的算法,把它們一個個封裝起來,并且使它們可相互替換。本模式使得算法的變化可獨立于使用它的客戶 | ||
| 訪問者模式 | 表示一個作用于某對象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作 |
003 常見導(dǎo)致重新設(shè)計的場景
| 場景 | 場景描述 | 解決方案 |
|---|---|---|
| 通過顯式地指定一個類來創(chuàng)建對象 | 在創(chuàng)建對象時指定類名將使你受特定實現(xiàn)的約束而不是特定接口的約束。這會使未來的變化更復(fù)雜。要避免這種情況，應(yīng)該間接地創(chuàng)建對象 | 抽象工廠模式 工廠方法模式 原型模式 |
| 對特殊操作的依賴 | 當你為請求指定一個特殊的操作時，完成該請求的方式就固定下來了。為避免把請求代碼寫死，你將可以在編譯時刻或運行時刻很方便地改變響應(yīng)請求的方法 | 職責鏈模式 命令模式 |
| 對硬件和軟件平臺的依賴 | 外部的操作系統(tǒng)接口和應(yīng)用編程接口(API)在不同的軟硬件平臺上是不同的。依賴于特定平臺的軟件將很難移植到其他平臺上，甚至都很難跟上本地平臺的更新。所以設(shè)計系統(tǒng)時限制其平臺相關(guān)性就很重要了 | 抽象工廠模式 橋接模式 |
| 對對象表示或?qū)崿F(xiàn)的依賴 | 知道對象怎樣表示、保存、定位或?qū)崿F(xiàn)的客戶在對象發(fā)生變化時可能也需要變化。對客戶隱藏這些信息能阻止連鎖變化 | 抽象工廠模式 橋接模式 備忘錄模式 代理模式 |
| 算法依賴算法在開發(fā)和復(fù)用時常常被擴展、優(yōu)化和替代 | 依賴于某個特定算法的對象在算法發(fā)生變化時不得不變化。因此有可能發(fā)生變化的算法應(yīng)該被孤立起來 | 建造者模式 迭代器模式 策略模式 模板方法模式 訪問者模式 |
| 緊耦合緊耦合的類很難獨立地被復(fù)用，因為它們是互相依賴的 | 緊耦合產(chǎn)生單塊的系統(tǒng)，要改變或刪掉一個類，你必須理解和改變其他許多類。這樣的系統(tǒng)是一個很難學(xué)習、移植和維護的密集體。 松散耦合提高了一個類本身被復(fù)用的可能性，并且系統(tǒng)更易于學(xué)習、移植、修改和擴展。設(shè)計模式使用抽象耦合和分層技術(shù)來提高系統(tǒng)的松散耦合性 | 抽象工廠模式 命令模式 外觀模式 中介者模式 觀察者模式 職責鏈模式 |
| 通過生成子類來擴充功能通常很難通過定義子類來定制對象 | 每一個新類都有固定的實現(xiàn)開銷(初始化、終止處理等)。定義子類還需要對父類有深入的了解。如，重定義一個操作可能需要重定義其他操作。一個被重定義的操作可能需要調(diào)用繼承下來的操作。并且子類方法會導(dǎo)致類爆炸，因為即使對于一個簡單的擴充，你也不得不引入許多新的子類。 一般的對象組合技術(shù)和具體的委托技術(shù)，是繼承之外組合對象行為的另一種靈活方法。新的功能可以通過以新的方式組合已有對象，而不是通過定義已存在類的子類的方式加到應(yīng)用中去。另一方面，過多使用對象組合會使設(shè)計難于理解。許多設(shè)計模式產(chǎn)生的設(shè)計中，你可以定義一個子類，且將它的實例和已存在實例進行組合來引入定制的功能 | 橋接模式 職責鏈模式 組合模式 裝飾器模式 觀察者模式 策略模式 |
| 不能方便地對類進行修改有時你不得不改變一個難以修改的類 | 也許你需要源代碼而又沒有(對于商業(yè)類庫就有這種情況)，或者可能對類的任何改變會要求修改許多已存在的其他子類。設(shè)計模式提供在這些情況下對類進行修改的方法 | 適配器模式 裝飾器模式 訪問者模式 |
004 使用設(shè)計模式存在的缺陷
設(shè)計模式引入額外的間接層次獲得靈活性和可變性的同時，也使設(shè)計變得更復(fù)雜或犧牲了一定的性能。一個設(shè)計模式只有當它提供的靈活性是真正需要的時候，才有必要使用。
