一、單件模式

動機（Motivation):
    在軟體系統中，經常有這樣一些特殊的類，必須保證它們在系統中只存在一個例項，才能確保它們的邏輯正確性、以及良好的效率。
    如何繞過常規的構造器，提供一種機制來保證一個類只建立一個例項？
這應該是類設計者的責任，而不是類使用者的責任。

      
意圖：
    保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。
                                ------<<設計模式>>GOF         
適用性：
   （1）當類只能有一個例項而且客戶可以從一個眾所周知的訪問點訪問它時。
   （2）當這個唯一例項應該是通過子類化可擴充套件的，並且客戶應該無需更改程式碼就能使用一個擴充套件的例項時。

  程式碼實現：
（1）單執行緒Singleton實現

以上程式碼在單執行緒情況下不會出現任何問題。但是在多執行緒的情況下卻不是安全的。
如兩個執行緒同時執行到if (instance ==null)判斷是否被例項化，一個執行緒判斷為True後，在進行建立
 instance =new SingleThread_Singleton();之前，另一個執行緒也判斷(instance ==null)，結果也為True.
這樣就就違背了Singleton模式的原則（保證一個類僅有一個例項）。
怎樣在多執行緒情況下實現Singleton？
（2）多執行緒Singleton實現：

class MultiThread_Singleton { private static volatile MultiThread_Singleton instance = null; private static object lockHelper = new object(); private MultiThread_Singleton() { } public static MultiThread_Singleton Instance { get { if (instance == null) { lock (lockHelper) { if (instance == null) { instance = new MultiThread_Singleton(); } } } return instance; } }

此程式對多執行緒是安全的，使用了一個輔助物件lockHelper，保證只有一個執行緒建立例項（如果instance為空，保證只有一個執行緒instance =new MultiThread_Singleton();建立唯一的一個例項）。

(3)靜態Singleton實現

class Static_Singleton { public static readonly Static_Singleton instance = new Static_Singleton(); private Static_Singleton() { } } 以上程式碼展開等同於 class Static_Singleton { public static readonly Static_Singleton instance; static Static_Singleton() { instance = new Static_Singleton(); } private Static_Singleton() { } }

由此可以看出，完全符合Singleton的原則。
優點： 簡潔，易懂
缺點： 不可以實現帶引數例項的建立。

二、介面卡模式

適配（轉換）的概念無處不在......
適配，即在不改變原有實現的基礎上，將原先不相容的介面轉換為相容的介面。 
動機(Motivate):
    在軟體系統中，由於應用環境的變化，常常需要將“一些現存的物件”放在新的環境中應用，但是新環境要求的介面是這些現存物件所不滿足的。
    那麼如何應對這種“遷移的變化”？如何既能利用現有物件的良好實現，同時又能滿足新的應用環境所要求的介面？這就是本文要說的Adapter模式。
意圖(Intent):
   將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。
                                                                            -------《設計模式》GOF    
適用性：

    1．系統需要使用現有的類，而此類的介面不符合系統的需要。

    2．想要建立一個可以重複使用的類，用於與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作。這些源類不一定有很複雜的介面。

    3．（對物件介面卡而言）在設計裡，需要改變多個已有子類的介面，如果使用類的介面卡模式，就要針對每一個子類做一個介面卡，而這不太實際。
示意性程式碼例項：

interface IStack { void Push(object item); void Pop(); object Peek(); } //物件介面卡(Adapter與Adaptee組合的關係) public class Adapter : IStack //適配物件 { ArrayList adaptee;//被適配的物件 public Adapter() { adaptee = new ArrayList(); } public void Push(object item) { adaptee.Add(item); } public void Pop() { adaptee.RemoveAt(adaptee.Count - 1); } public object Peek() { return adaptee[adaptee.Count - 1]; } } 類介面卡 public class Adapter :ArrayList, IStack { public void Push(object item) { this.Add(item); } public void Pop() { this.RemoveAt(this.Count - 1); } public object Peek() { return this[this.Count - 1]; } }

Adapter模式的幾個要點：
    Adapter模式主要應用於“希望複用一些現存的類，但是介面又與複用環境要求不一致的情況”，在遺留程式碼複用、類庫遷移等方面非常有用。
    GOF23定義了兩種Adapter模式的實現結構：物件介面卡和類介面卡。但類介面卡採用“多繼承”的實現方式，帶來不良的高耦合，所以一般不推薦使用。物件介面卡採用“物件組合”的方式，更符合鬆耦合精神。
    Adapter模式可以實現的非常靈活，不必拘泥於GOF23中定義的兩種結構。例如，完全可以將Adapter模式中的“現存物件“作為新的介面方法引數，來達到適配的目的。
    Adapter模式本身要求我們儘可能地使用”面向介面的程式設計"風格，這樣才能在後期很方便的適配。
.NET框架中的Adapter應用：
(1)在.Net中複用com物件：
 Com 物件不符合.net物件的介面
使用tlbimp.exe來建立一個Runtime Callable Wrapper(RCW)以使其符合.net物件的介面。
(2).NET資料訪問類（Adapter變體）：
各種資料庫並沒有提供DataSet介面
使用DBDataAdapter可以將任何各資料庫訪問/存取適配到一個DataSet物件上。
(3)集合類中對現有物件的排序（Adapter變體）;
現有物件未實現IComparable介面
實現一個排序介面卡（繼承IComparer介面），然後在其Compare方法中對兩個物件進行比較。

三、訪問者模式

動機：
    在軟體構建過程中，由於需求的改變，某些類層次結構中常常需要增加新的行為(方法),如果直接在基類中做這樣的更改，將會給子類帶來很繁重的變更負擔，甚至破壞原有設計。
    如何在不更改類層次結構的前提下，在執行時根據需要透明地為類層次結構上的各個類動態新增新的操作，從而避免上述問題？
意圖：
    表示一個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這引起元素的新操作。

適用性：
    1.一個物件結構包含很多類物件，它們有不同的介面，而你想對這些物件實施一些依賴於其具體類的操作。
    2.需要對一個物件結構中的物件進行很多不同的並且不相關的操作，而你想避免讓這些操作"汙染"這些物件的類。Visitor使得你可以將相關的操作集中起來定義在一個類中。當該物件結構被很多應用共享時，用Visitor模式讓每個應用僅包含需要用到的操作。
    3.定義物件結構的類很少改變，但經常需要在結構上定義新的操作。改變物件結構類需要重定義對所有訪問者的介面，這可能需要很大的代價。如果物件結構類經常改變，那麼可能還是在這些類中定義這些操作較好。
程式碼實現：

// MainApp startup application class MainApp { static void Main() { // Setup employee collection Employees e = new Employees(); e.Attach(new Clerk()); e.Attach(new Director()); e.Attach(new President()); // Employees are 'visited' e.Accept(new IncomeVisitor()); e.Accept(new VacationVisitor()); // Wait for user Console.Read(); } } // "Visitor" interface IVisitor { void Visit(Element element); } // "ConcreteVisitor1" class IncomeVisitor : IVisitor { public void Visit(Element element) { Employee employee = element as Employee; // Provide 10% pay raise employee.Income *= 1.10; Console.WriteLine("{0} {1}'s new income: {2:C}", employee.GetType().Name, employee.Name, employee.Income); } } // "ConcreteVisitor2" class VacationVisitor : IVisitor { public void Visit(Element element) { Employee employee = element as Employee; // Provide 3 extra vacation days Console.WriteLine("{0} {1}'s new vacation days: {2}", employee.GetType().Name, employee.Name, employee.VacationDays); } } class Clerk : Employee { // Constructor public Clerk() : base("Hank", 25000.0, 14) { } } class Director : Employee { // Constructor public Director() : base("Elly", 35000.0, 16) { } } class President : Employee { // Constructor public President() : base("Dick", 45000.0, 21) { } } // "Element" abstract class Element { public abstract void Accept(IVisitor visitor); } // "ConcreteElement" class Employee : Element { string name; double income; int vacationDays; // Constructor public Employee(string name, double income, int vacationDays) { this.name = name; this.income = income; this.vacationDays = vacationDays; } // Properties public string Name { get{ return name; } set{ name = value; } } public double Income { get{ return income; } set{ income = value; } } public int VacationDays { get{ return vacationDays; } set{ vacationDays = value; } } public override void Accept(IVisitor visitor) { visitor.Visit(this); } } // "ObjectStructure" class Employees { private ArrayList employees = new ArrayList(); public void Attach(Employee employee) { employees.Add(employee); } public void Detach(Employee employee) { employees.Remove(employee); } public void Accept(IVisitor visitor) { foreach (Employee e in employees) { e.Accept(visitor); } Console.WriteLine(); } 157 }

執行結果：
       
Visoitr模式的幾個要點：
    1.Visitor模式通過所謂雙重分發(double dispatch)來實現在不更改Element類層次結構的前提下，在執行時透明地為類層次結構上的各個類動態新增新的操作。
    2.所謂雙重分發卻Visotor模式中間包括了兩個多型分發（注意其中的多型機制);第一個為accept方法的多型辨析;第二個為visitor方法的多型辨析。
    3.Visotor模式的最大缺點在於擴充套件類層次結構(增添新的Element子類），會導致Visitor類的改變。因此Visiotr模式適用"Element"類層次結構穩定，而其中的操作卻經常面臨頻繁改動".