設計模式——什麼是設計模式

我的在CSDN上的相關BLOG：http://blog.csdn.net/feb13/article/details/7824565

讀《設計模式——可複用面向對象軟件的基礎》時候作的筆記。下面的文字及圖表基本上是該書的內容。
 

什麼是設計模式

一個設計模式有4個基本要素：

模式名稱（pattern name）一個幫助記憶的詞彙。用一兩個詞來描述模式的問題、解決方案和效果。設計模式容許咱們在較高的抽象層次上進行設計。

問題（problem）描述了應該在何時或者什麼狀況下使用該模式。它解釋了設計問題和問題存在的來龍去脈，它可能描述了特色的設計問題，也可能描述了致使不靈活設計的類或對象結構。

解決方案（solution）描述了設計的組成成分，它們之間的相互關係以及各自的職責和協助方式。

效果（consequences）描述了模式應用的效果及使用模式應權衡的問題。它們對於評價設計選擇和理解使用模式的代價及好處具備重要意義。由於複用是面向對象設計的要素之一，因此模式效果包括它對系統的靈活性、擴充性或可移植性的影響，顯示地列出這些效果對理解和評價這些模式頗有幫助。

 設計模式是對被用來在特定場景下解決通常設計問題的類和相互通訊的對象的描述。

 一個設計模式命名、抽象和肯定了一個通用設計結構的主要方面，這些設計結構能被用來構造可複用的面向對象設計。設計模式肯定了所包含的類和實例，它們的角色、協做方式以及職責分配。每個設計模式都集中於一個特定的面向對象設計問題或設計要點，描述了何時使用它，在另外一些設計約束條件下是否還能使用，以及使用的效果和如何取捨。

 

23種設計模式的基本意圖

抽象工廠（Abstract Factory）提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類。

適配器（Adapter）將一個類的接口轉換成客戶但願的另外一個接口。Adapter模式使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做。

橋接（Bridge）將抽象部分與它的實現部分分離，使他們均可以獨立地變化。

生成器（Builder）將一個複雜的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。

職責鏈（Chain ofResponsibility） 爲解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象練成一條鏈，並沿用這條鏈傳遞該請求，直到有一個對象處理它。

命令（Command）將一個請求封裝爲一個對象，從而使你可用不一樣的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可取消的操做。

組成（Composite）將對象組合成樹形結構以表示「部分-總體」的層次結構。Composite使得客戶對每一個對象和複合對象的使用具備一致性。

裝飾（Decorator）動態地給一個對象添加一些額外的職責。就擴展功能而言，Decorator模式比生成子類的方式更爲靈活。

外觀（Facade）爲子系統中的一組接口提供一個一致的界面，Façade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

工廠方法（Factory Method）定義一個用於建立對象的接口，讓子類決定將哪個類實例化。Factory Method使一個類的實例化延遲到其子類。

享元（Flyweight）運用共享技術有效地支持大量細粒度的對象。

解釋器（Interpreter）給定一個語言，定義它的文法的一種表示，並定義一個解釋器，該解釋器使用文法表示來解釋語言中的句子。

迭代器（Iterator）提供一種方法順序訪問一個聚合對象中各個元素，而又不須要暴露該對象的內部表示。

中介者（Mediator）用一箇中介對象來封裝一系列的對象交互。中介者使各對象不須要顯式地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。

備忘錄（Memento）在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。這樣之後就可將該對象恢復到保存的狀態。

觀察者（Observer）定義對象間的一種一對多的依賴關係，以便當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並自動刷新。

原型（Prototype）用原型實例指定建立對象的種類，而且經過拷貝這個原型來建立新的對象。

代理（Proxy）爲其餘對象提供一個代理以控制對這個對象的訪問。

單例（Singleton）保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。

狀態（State）容許一個對象在其內部狀態改變時改變它的行爲。對象看起來彷佛修改了它所屬的類。

策略（Strategy）定義一系列的算法，把它們一個個封裝起來，而且使它們可相互替換。本模式使得算法的變化可獨立於使用它的客戶。

模板方法（Template Method）定義一個操做中的算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。

發問者（Visitor）表示一個做用於某對象結構中的各元素的操做。它使你能夠在不改變各元素的類的前提下定義做用餘這些元素的新操做。

 

設計模式的分類

目的 範圍	建立型	結構型	行爲型
類	Factory Method	Adapter（類）	Interpreter Template Method
對象	Abstract Factory Builder Prototype Singleton	Adapter（對象） Bridge Composite Decorator Façade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Mementor Observer State Strategy Visitor

以上的分類是根據兩條準則進行的。

第一是目的準則，即模式是用來完成什麼工做的。模式依據其目的分爲建立型、結構型、行爲型三種。建立型模式與對象的建立有關；結構型模式處理類或對象的組合；行爲型模式對類或對象怎樣交互和怎樣分配職責進行描述。

第二是範圍準則，指定模式主要是用於類仍是用於對象。類模式處理類和子類之間的關係，這些關係經過繼承創建，是靜態的，在編譯時刻便肯定下來。對象模式處理對象間的關係，這些關係在運行時刻是變化的，更具動態性。

建立型類模式將對象的部分建立工做延遲到子類，而建立型對象模式則將它延遲到另外一個對象中。結構型類模式使用繼承機制來組合類，而結構型對象模式則描述了對象的組裝方式。行爲型類模式使用繼承描述算法和控制流，而行爲型對象模式則描述一組對象怎樣協做完成單個對象所沒法完成的任務。

 

設計模式之間的關係

 

 

相關問題的設計模式解決方案

可複用的面向對象設計有如下原則：

針對接口編程，而不是針對實現編程；

優先使用對象組合，而不是類繼承

 

下面闡述了一些致使從新設計的通常緣由，以及解決這些問題的設計模式：

1） 經過顯式地指定一個類來建立對象

在建立對象時指定類名將使你受特定實現類約束而不是受特定接口約束。這會使將來的變化更復雜。要避免這種狀況，應該間接地建立對象。

設計模式：Abstract Factory，FactoryMethod，Prototype

2） 對特殊操做的依賴

當你爲請求指定一個特殊的操做時，完成該請求的方式就固定下來。爲避免把請求代碼寫死，你將能夠在編譯時刻或運行時刻很方便地響應請求的方法。

設計模式：Chain of Responsibility，Command

3） 對硬件和軟件平臺的依賴

外部的操做系統接口和應用編程接口（API）在不一樣平臺上是不一樣的。依賴於特定平臺的軟件將很難移植到其餘平臺上，甚至都很難跟上本地平臺的更新。因此設計系統時限制其平臺相關性就很重要了。

設計模式：Abstract Factory，Bridge

4） 對對象表示或實現的依賴

知道對象怎樣表示、保存、定位或實現的客戶在對象發生變化時可能也須要變化。對客戶隱藏這些信息能阻止連鎖變化。

設計模式：Abstract Factory，Bridge，Memento，Proxy

5） 算法依賴

算法在開發和複用時經常被擴展、優化和替代。依賴於某個特定算法的對象在算法發生變化時不得不變化。所以有可能發生變化的算法應該孤立起來。

設計模式：Builder，Iterator，Strategy，TemplateMethod，Visitor

6） 緊耦合

緊耦合的類很難獨立地被複用，由於它們是互相依賴的。緊耦合產生單塊的系統，要改變或刪掉一個類，你必須理解和改變其餘許多類。這樣的系統是一個很難學習、移植和維護的密集體。

鬆耦合提升了一個類自己被複用的可能性，而且系統更易於學習、移植、修改和擴展。設計模式使用抽象耦合和分層技術來提升系統的鬆耦合性。

設計模式：Abstract Factory，Command，Façade，Mediator，Observer，

Chain of Responsibility

7） 經過生成子類來擴充功能

通 常很難經過定義子類來定製對象。每個新類都有固定的實現開銷（初始化、終止處理等）。定義子類還須要對父類有深刻的瞭解。如，重定義一個方法可能須要重 定義其餘方法。一個被重定義的方法可能須要調用繼承下了的方法。而且子類方法會致使類爆炸，由於即便對於一個簡單的擴充，你也不得不引入許多新的子類。

通常的對象組合技術和具體的委託技術，是繼承以外組合對象行爲的另外一種靈活方法。新的功能能夠經過新的方式組合已有對象，而不是經過定義已存在類的子類的方式加到應用中。另外一方面，過多使用對象組合會使設計難於理解。

設計模式：Bridge，Chain ofResponsibility，Composite，Decorator，Observer，

Strategy

8） 不能方便地對類進行修改

有時你不得不改變一個難以修改的類。也許你須要源代碼而又沒有（對於商業類庫），或者可能對類的任何改變會要求修改許多已存在的其餘子類。

設計模式：Adapter，Decorator，Visitor

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

目的	設計模式	可變的方面
建立	Abstract Factory	產品對象家族
	Builder	如何建立一個組合對象
	Factory Method	被實例化的子類
	Prototype	被實例化的類
	Singleton	一個類的惟一實例
結構	Adapter	對象的接口
	Bridge	對象的實現
	Composite	一個對象的結構和組成
	Decorator	對象的職責，不生成子類
	Façade	一個子系統的接口
	Flyweight	對象的存儲開銷
	Proxy	如何訪問一個對象；該對象的位置
行爲	Chain of Responsibility	知足一個請求的對象
	Command	什麼時候、怎樣知足一個請求
	Interpreter	一個語言的文法和解釋
	Iterator	如何遍歷、訪問一個聚合的各元素
	Mediator	對象間怎樣交互、和誰交互
	Memento	一個對象中哪些私有信息存在該對象以外，以及在何時進行存儲
	Observer	多個對象依賴於另外一個對象，而這些對象又如何保持一致
	State	對象的狀態
	Strategy	算法
	Template Method	算法中的某些步驟
	Visitor	某些可做用於一個（組）對象上的操做，但不修改這些對象的類