Win8.1应用开发之适配器模式（C#实现）

实际上适配器模式是用于解耦。设想一下我们的程序模块A在与模块B打交道时，需要在许多地方多次使用B中某个类的方法，而负责开发B的程序猿Tom还未完全实 现该类，会随时更改该类中的方法，那么当Tom在修改时，负责A的攻城狮Jerry不得不进行苦逼的修改。聪明的项目经理Dabao想出了好方法——适配器模式，于是在Tom和Jerry之间进行了如下设计：

/// <summary> 
   /// B中目前只定义了英雄KASS 
   /// </summary> 
   public class KASS 
   { 
       public void R() 
       { 
           //KASS的技能 
       } 
   } 
 
 
       /// <summary> 
   /// 定义英雄的接口 
   /// </summary> 
   public class Hero 
   { 
       /// <summary> 
       /// 使用virtual修饰以便子类可以重写 
       /// </summary> 
       public virtual void attack() 
       { 
           //英雄进攻的方法和招数 
       } 
   } 
 
 
   /// <summary> 
   /// 定义适配器 
       /// B暂时提供英雄KASS 
   /// </summary> 
   public class HeroAdapter:Hero 
   { 
       // 建立一个私有的英雄KASS对象 
       private KASS kass = new KASS(); 
 
       /// <summary> 
       /// 通过重写，表面上调用attack()方法，实际调用R() 
       /// </summary> 
       public override void attack() 
       { 
           kass.R(); 
       } 
   } 
       
       
       /// <summary> 
   /// Tom负责的模块A 
   /// </summary> 
       public class A 
   { 
       public static void Main(string[] args) 
       { 
           // A需要借助B中的英雄完成进攻的任务，但B还未定下是那个英雄，所以不能直接创建特定英雄的对象 
                       // 但我们知道肯定要一个英雄，并且需要这个英雄去进攻 
           Hero hero = new HeroAdapter(); 
           hero.attack(); 
 
           //... 
       } 
   } 

这样 有一天B将KASS替换成另一个英雄后，A不需要进行任何改动，只要将适配器HeroAdapter中的英雄替换为B修改后的新英雄，并将attack方 法中的实现换成新英雄的技能即可。任A多次使用英雄，最终只需修改一个适配器即可，这就实现了A和B的解耦。实际上我认为适配器的另一个作用是担当了A和 B之间沟通的桥梁：HeroAdapter出现在A中，同时HeroAdapter中包含B中的元素。负责B的Tom通过适配器明白他创建的英雄要能够完 成A中进攻的任务。

这里再举一个实际开发的例子进一步探讨一下适配器模式。

Win8.1 Metro开发中，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; } 
 
        } 
 
} 

我会向服务器请求该对象的JSON形式，服务器端根据大学Id将大 学信息找到后组织到自己定义的类中，由于XAML绑定的缘故，我无法直接使用服务器端自己定义的类形式，这势必要经过一道工序，将服务器端的类形式转化为 我需要的类形式，这就好比外国朋友电器的插头不能适应我们国家的插座，那就需要一个适配器，通过适配器插到我们的插座上。其实上面的大学类就相当于这个适 配器，我将这个类告知负责服务器端开发的队友，他根据这个类的形式重新组织要发送的JSON。而我这边不需要再进行转化。