實際上適配器模式是用于解耦。設(shè)想一下我們的程序模塊A在與模塊B打交道時，需要在許多地方多次使用B中某個類的方法，而負責(zé)開發(fā)B的程序猿Tom還未完全實 現(xiàn)該類，會隨時更改該類中的方法，那么當(dāng)Tom在修改時，負責(zé)A的攻城獅Jerry不得不進行苦逼的修改。聰明的項目經(jīng)理Dabao想出了好方法——適配器模式，于是在Tom和Jerry之間進行了如下設(shè)計：

/// <summary> 
   /// B中目前只定義了英雄KASS 
   /// </summary> 
   public class KASS 
   { 
       public void R() 
       { 
           //KASS的技能 
       } 
   } 
 
 
       /// <summary> 
   /// 定義英雄的接口 
   /// </summary> 
   public class Hero 
   { 
       /// <summary> 
       /// 使用virtual修飾以便子類可以重寫 
       /// </summary> 
       public virtual void attack() 
       { 
           //英雄進攻的方法和招數(shù) 
       } 
   } 
 
 
   /// <summary> 
   /// 定義適配器 
       /// B暫時提供英雄KASS 
   /// </summary> 
   public class HeroAdapter:Hero 
   { 
       // 建立一個私有的英雄KASS對象 
       private KASS kass = new KASS(); 
 
       /// <summary> 
       /// 通過重寫，表面上調(diào)用attack()方法，實際調(diào)用R() 
       /// </summary> 
       public override void attack() 
       { 
           kass.R(); 
       } 
   } 
       
       
       /// <summary> 
   /// Tom負責(zé)的模塊A 
   /// </summary> 
       public class A 
   { 
       public static void Main(string[] args) 
       { 
           // A需要借助B中的英雄完成進攻的任務(wù)，但B還未定下是那個英雄，所以不能直接創(chuàng)建特定英雄的對象 
                       // 但我們知道肯定要一個英雄，并且需要這個英雄去進攻 
           Hero hero = new HeroAdapter(); 
           hero.attack(); 
 
           //... 
       } 
   } 

這樣 有一天B將KASS替換成另一個英雄后，A不需要進行任何改動，只要將適配器HeroAdapter中的英雄替換為B修改后的新英雄，并將attack方 法中的實現(xiàn)換成新英雄的技能即可。任A多次使用英雄，最終只需修改一個適配器即可，這就實現(xiàn)了A和B的解耦。實際上我認為適配器的另一個作用是擔(dān)當(dāng)了A和 B之間溝通的橋梁：HeroAdapter出現(xiàn)在A中，同時HeroAdapter中包含B中的元素。負責(zé)B的Tom通過適配器明白他創(chuàng)建的英雄要能夠完 成A中進攻的任務(wù)。

這里再舉一個實際開發(fā)的例子進一步探討一下適配器模式。

Win8.1 Metro開發(fā)中，XAML綁定了一個對象University

using demo02.Helper; 
using System; 
using System.Collections.Generic; 
using System.Collections.ObjectModel; 
using System.Linq; 
using System.Text; 
using System.Threading.Tasks; 
 
namespace demo02.DataModel 
{ 
 
        public class University : Base 
        { 
          
            public University(String id, String name, String summary, String imagePath, String category, double stars, String tileImagePath) 
                : base(id, name, summary, imagePath) 
            { 
                this.Category = category; 
                this.Stars = stars; 
                this.Projects = new ObservableCollection<Project>(); 
                this.Images = new ImageHelper(); 
                this.TileImagePath = tileImagePath; 
            } 
 
            public string TileImagePath { get; set; } 
            public string Category { get; set; } 
            public double Stars { get; set; } 
            public ObservableCollection<Project> Projects { get; set; } 
 
            public int ClickTimes { get; set; } 
            //兼容 
            public ImageHelper Images { get; set; } 
 
        } 
 
} 

我會向服務(wù)器請求該對象的JSON形式，服務(wù)器端根據(jù)大學(xué)Id將大 學(xué)信息找到后組織到自己定義的類中，由于XAML綁定的緣故，我無法直接使用服務(wù)器端自己定義的類形式，這勢必要經(jīng)過一道工序，將服務(wù)器端的類形式轉(zhuǎn)化為 我需要的類形式，這就好比外國朋友電器的插頭不能適應(yīng)我們國家的插座，那就需要一個適配器，通過適配器插到我們的插座上。其實上面的大學(xué)類就相當(dāng)于這個適 配器，我將這個類告知負責(zé)服務(wù)器端開發(fā)的隊友，他根據(jù)這個類的形式重新組織要發(fā)送的JSON。而我這邊不需要再進行轉(zhuǎn)化。