意圖定義一系列的算法，把它們一個一個封裝起來，並且使它們可相互替換。本模式使得算法可以獨立於它的客戶而變化。場景在開發程序的時候，我們經常會根據環境不同采取不

意圖將對象組合成樹形結構以表示“部分-整體”的層次結構。Composite模式使得用戶對單個對象和組合對象的使用具有一致性。場景我們知道，一個網絡游戲通常會有

代碼執行結果如下圖：代碼說明l　Element類型就是抽象構件的角色，它給組合對象以及單個對象提供了一個一致的接口，使得它們都能有一致的行為。l　這裡就出現一

意圖運用共享技術有效地支持大量細粒度的對象。場景在比較底層的系統或者框架級的軟件系統中，通常存在大量細粒度的對象。即使細力度的對象，如果使用的數量級很高的話會

代碼執行結果如下圖（前面是使用享元模式的結果，後面是沒有使用享元模式的結果）：代碼說明l　這裡的ModelFactory就是享元工廠角色。它的作用是創建和管理

代碼說明l　IAccount就是抽象主題角色。代理對象和被代理對象都遵循這個接口，這樣代理對象就能替換被代理對象。l　AccountProxy就是代理主題角色

意圖為子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。場景在一個為游戲充值的網站中，創建訂單需要

代碼說明l　PayFacade類就是門面類型，提供給客戶端調用，它本身調用子接口。可以看到，創建一個訂單首先要根據用戶名獲取用戶ID、然後要看用戶是否已經激活

意圖把一個類的接口變換成客戶端所期待的另一種接口，從而使原本接口不匹配而無法在一起工作的兩個類能夠在一起工作。場景假設網絡游戲的客戶端程序分兩部分。一部分是和

代碼執行結果如下圖：代碼說明l　可以看到，原先的接口中，啟動游戲場景只需要一個參數，就是游戲場景名，而進入新的玩家需要提供玩家ID（新游戲都使用玩家ID而不使

意圖將一個復雜的構建與其表示相分離，使得同樣的構建過程可以創建不同的表示。場景在電腦城裝機總有這樣的經歷。我們到了店裡，先會有一個銷售人員來詢問你希望裝的機器

示例代碼using System;using System.Collections.Generic;using System.Text;using Syste

意圖用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。場景游戲場景中的有很多相似的敵人，它們的技能都一樣，但是隨著敵人出現的位置不同，這些人的能

碼執行結果如下圖：代碼說明l　Enemy類是抽象原型，它有兩個用途，一是定義了原型的一些抽象內容，二是定義了原型模式必須的拷貝方法。在這裡，我們看到，每個敵人

何時采用l　從代碼角度來說， 如果你希望運行時指定具體類（比如是使用Footman作為敵人還是使用其它），或者你希望避免創建對象時的初始化過程（如果這個過程占

意圖定義一個創建產品對象的工廠接口，將實際創建工作推遲到子類中。場景上次，我們使用抽象工廠解決了生產一組產品的問題，但是我們把各個場景作為了具體工廠來生產場景

代碼執行結果如下圖：代碼說明l　這個代碼基於前一節抽象工廠的代碼修改而來，因此代碼比較廠。其中能體現的設計模式有抽象工廠、工廠方法以及模版方法。l　這次的Pa

何時采用l　從代碼角度來說， 如果你希望分離復雜類型構建規則和類型內部組成，或者希望把相同的構建過程用於構建不同類型的時候可以考慮使用建造者模式。l　從應用角

意圖提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。場景還是上次說的那個網絡游戲，定下來是一個休閒的FPS游戲。和CS差不多，8到16個玩

.Net中的抽象工廠l　我們說過，抽象工廠針對系列產品的應變。在使用ADO.NET進行數據訪問的時候，如果目標數據庫是Access，我們會使用OleDbCon