轉載自 http://www.cnblogs.com/zhili/p/AdapterPattern.html

一、引言

在實際的開發過程中，由於應用環境的變化（例如使用語言的變化），我們需要的實現在新的環境中沒有現存對象可以滿足，但是其他環境卻存在這樣現存的對象。那麽如果將“將現存的對象”在新的環境中進行調用呢？解決這個問題的辦法就是我們本文要介紹的適配器模式——使得新環境中不需要去重復實現已經存在了的實現而很好地把現有對象（指原來環境中的現有對象）加入到新環境來使用。

二、適配器模式的詳細介紹

2.1 定義

下面讓我們看看適配器的定義，適配器模式——把一個類的接口變換成客戶端所期待的另一種接口，從而使原本接口不匹配而無法一起工作的兩個類能夠在一起工作。適配器模式有類的適配器模式和對象的適配器模式兩種形式，下面我們分別討論這兩種形式的實現和給出對應的類圖來幫助大家理清類之間的關系。

2.2 類的適配器模式實現

在這裏以生活中的一個例子來進行演示適配器模式的實現，具體場景是: 在生活中，我們買的電器插頭是2個孔的，但是我們買的插座只有三個孔的，此時我們就希望電器的插頭可以轉換為三個孔的就好，這樣我們就可以直接把它插在插座上，此時三個孔插頭就是客戶端期待的另一種接口，自然兩個孔的插頭就是現有的接口，適配器模式就是用來完成這種轉換的，具體實現代碼如下：

using System;

/// 這裏以插座和插頭的例子來詮釋適配器模式
/// 現在我們買的電器插頭是2個孔，但是我們買的插座只有3個孔的
/// 這是我們想把電器插在插座上的話就需要一個電適配器
namespace 設計模式之適配器模式
{
    
 
/// <summary>
    /// 客戶端，客戶想要把2個孔的插頭 轉變成三個孔的插頭，這個轉變交給適配器就好
    /// 既然適配器需要完成這個功能，所以它必須同時具體2個孔插頭和三個孔插頭的特征
    /// </summary>
    class Client
    {
        static void Main(string[] args)
        {
            // 現在客戶端可以通過電適配要使用2個孔的插頭了
            IThreeHole threehole = new PowerAdapter();
            threehole.Request();
            Console.ReadLine();
        }
    }

    
 
/// <summary>
    /// 三個孔的插頭，也就是適配器模式中的目標角色
    /// </summary>
    public interface IThreeHole
    {
        void Request();
    }

    /// <summary>
    /// 兩個孔的插頭，源角色——需要適配的類
    /// </summary>
    public abstract class TwoHole
    {
        public void SpecificRequest()
        {
            Console.WriteLine("我是兩個孔的插頭");
        }
    }

    /// <summary>
    /// 適配器類，接口要放在類的後面
    /// 適配器類提供了三個孔插頭的行為，但其本質是調用兩個孔插頭的方法
    /// </summary>
    public class PowerAdapter:TwoHole,IThreeHole
    {
        /// <summary>
        /// 實現三個孔插頭接口方法
        /// </summary>
        public void Request()
        {
            // 調用兩個孔插頭方法
            this.SpecificRequest();
        }
    }
}

從上面代碼中可以看出，客戶端希望調用Request方法（即三個孔插頭），但是我們現有的類（即2個孔的插頭）並沒有Request方法，它只有SpecificRequest方法（即兩個孔插頭本身的方法），然而適配器類（適配器必須實現三個孔插頭接口和繼承兩個孔插頭類）可以提供這種轉換，它提供了Request方法的實現（其內部調用的是兩個孔插頭，因為適配器只是一個外殼罷了，包裝著兩個孔插頭（因為只有這樣，電器才能使用），並向外界提供三個孔插頭的外觀，）以供客戶端使用。

2.3 類圖

上面實現中，因為適配器（PowerAdapter類）與源角色（TwoHole類）是繼承關系，所以該適配器模式是類的適配器模式，具體對應的類圖為：

2.4 對象的適配器模式

上面都是類的適配器模式的介紹，然而適配器模式還有另外一種形式——對象的適配器模式，這裏就具體講解下它的實現，實現的分析思路：既然現在適配器類不能繼承TwoHole抽象類了（因為用繼承就屬於類的適配器了），但是適配器類無論如何都要實現客戶端期待的方法的，即Request方法，所以一定是要繼承ThreeHole抽象類或IThreeHole接口的，然而適配器類的Request方法又必須調用TwoHole的SpecificRequest方法，又不能用繼承，這時候就想，不能繼承，但是我們可以在適配器類中創建TwoHole對象，然後在Requst中使用TwoHole的方法了。正如我們分析的那樣，對象的適配器模式的實現正式如此。下面就讓我看看具體實現代碼：

namespace 對象的適配器模式
{
    class Client
    {
        static void Main(string[] args)
        {
            // 現在客戶端可以通過電適配要使用2個孔的插頭了
            ThreeHole threehole = new PowerAdapter();
            threehole.Request();
            Console.ReadLine();
        }
    }

    /// <summary>
    /// 三個孔的插頭，也就是適配器模式中的目標(Target)角色
    /// </summary>
    public class ThreeHole
    {
        // 客戶端需要的方法
        public virtual void Request()
        {
            // 可以把一般實現放在這裏
        }
    }

    /// <summary>
    /// 兩個孔的插頭，源角色——需要適配的類
    /// </summary>
    public class TwoHole
    {
        public void SpecificRequest()
        {
            Console.WriteLine("我是兩個孔的插頭");
        }
    }

    /// <summary>
    /// 適配器類，這裏適配器類沒有TwoHole類，
    /// 而是引用了TwoHole對象，所以是對象的適配器模式的實現
    /// </summary>
    public class PowerAdapter : ThreeHole
    {
        // 引用兩個孔插頭的實例,從而將客戶端與TwoHole聯系起來
        public TwoHole twoholeAdaptee = new TwoHole();

        /// <summary>
        /// 實現三個孔插頭接口方法
        /// </summary>
        public override void Request()
        {
            twoholeAdaptee.SpecificRequest();
        }
    }
}

從上面代碼可以看出,對象的適配器模式正如我們開始分析的思路去實現的, 其中客戶端調用代碼和類的適配器實現基本相同,下面讓我們看看對象的適配器模式的類圖,具體類圖如下:

三、適配器模式的優缺點

在引言部分已經提出,適配器模式用來解決現有對象與客戶端期待接口不一致的問題,下面詳細總結下適配器兩種形式的優缺點。

類的適配器模式：

優點：

• 可以在不修改原有代碼的基礎上來復用現有類，很好地符合 “開閉原則”
• 可以重新定義Adaptee(被適配的類)的部分行為，因為在類適配器模式中，Adapter是Adaptee的子類
• 僅僅引入一個對象，並不需要額外的字段來引用Adaptee實例（這個即是優點也是缺點）。

缺點：

• 用一個具體的Adapter類對Adaptee和Target進行匹配，當如果想要匹配一個類以及所有它的子類時，類的適配器模式就不能勝任了。因為類的適配器模式中沒有引入Adaptee的實例，光調用this.SpecificRequest方法並不能去調用它對應子類的SpecificRequest方法。
• 采用了 “多繼承”的實現方式，帶來了不良的高耦合。

對象的適配器模式

優點：

• 可以在不修改原有代碼的基礎上來復用現有類，很好地符合 “開閉原則”（這點是兩種實現方式都具有的）
• 采用 “對象組合”的方式，更符合松耦合。

缺點：

• 使得重定義Adaptee的行為較困難，這就需要生成Adaptee的子類並且使得Adapter引用這個子類而不是引用Adaptee本身。

四、使用場景

在以下情況下可以考慮使用適配器模式：

1. 系統需要復用現有類，而該類的接口不符合系統的需求
2. 想要建立一個可重復使用的類，用於與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作。
3. 對於對象適配器模式，在設計裏需要改變多個已有子類的接口，如果使用類的適配器模式，就要針對每一個子類做一個適配器，而這不太實際。

六、總結

到這裏適配器模式的介紹就結束了，本文主要介紹了適配器模式的兩種實現、分析它們的優缺點以及使用場景的介紹，在適配器模式中，適配器可以是抽象類，並適配器模式的實現是非常靈活的，我們完全可以將Adapter模式中的“現存對象”作為新的接口方法參數，適配器類可以根據參數參數可以返回一個合適的實例給客戶端。

07.設計模式_適配器模式