其实适配器模式就是用来解耦的。想象一下，当我们的程序模块A处理模块B时，需要在很多地方多次使用B中某个类的方法，而负责开发B的程序员Tom还没有完全实现这个类，会改随时在类中的方法。method，那么Tom在修改的时候，负责A的攻城狮Jerry要硬修改。聪明的项目经理大宝想出了一个好方法——适配器模式，于是猫和老鼠之间做了如下设计：//////B目前只定义了英雄KASS///publicclassKASS{publicvoidR(){//KASS技巧}}//////定义hero接口///publicclassHero{//////对child类使用virtual修饰即可重写了///publicvirtualvoidattack(){//Hero攻击方法和技巧}}//////定义适配器///B暂时提供heroKASS///publicclassHeroAdapter:Hero{//创建私有heroKASS对象privateKASSkass=newKASS();//////通过重写，表面调用attack()方法，实际调用R()///publicoverridevoidattack(){kass.R();}}//////Tom负责模块A///publicclassA{publicstaticvoidMain(string[]args){//A需要使用B中的英雄完成进攻任务，但是B还没有确定是哪个英雄，所以we不能直接创建一个具体的英雄对象//但是我们知道我们必须有一个英雄，我们需要这个英雄来攻击Herohero=newHeroAdapter();hero.attack();//...}}这样，某天B将KASS换成另一个英雄后，A不需要做任何改动，只要将适配器HeroAdapter中的英雄换成B修改后的新英雄即可，攻击方法中的实现可以换成技能的新英雄。让A多次使用hero，最后只需要修改一个adapter，实现了A和B的解耦。其实我觉得adapter的另一个作用是充当A和B之间的桥梁：HeroAdapter出现在A，HeroAdapter包含B中的元素。负责B的Tom通过adapter了解到他的herocreates必须能够完成A中的进攻任务。这里再举一个实际开发的例子来进一步探索适配器模式。在Win8.1Metro开发中，XAML绑定了一个对象Universityusingdemo02.Helper;usingSystem;usingSystem.Collections.Generic;usingSystem.Collections.ObjectModel;usingSystem.Linq;usingSystem.Text;usingSystem.Threading.Tasks;namespacedemo02.DataModel{publicclassUniversity:Base{publicUniversity(Stringid,Stringname,Stringsummary,StringimagePath,Stringcategory,doublestars,StringtileImagePath):base(id,name,summary,imagePath){this.Category=category;this.Stars=stars;this.Projects=newObservableCollection<项目>();this.Images=newImageHelper();this.TileImagePath=tileImagePath;}publicstringTileImagePath{get;set;}publicstringCategory{get;set;}publicdoubleStars{get;set;}publicObservableCollectionProjects{get;set;}publicintClickTimes{get;set;}//兼容publicImageHelperImages{get;set;}}}我会向服务器请求对象的JSON形式，服务器会根据大学Id找到大学信息并整理进入自己定义的类，因为XAML绑定的缘故，我不能直接使用服务端定义的类形式。这就势必要经过一个过程，将服务器端的类形式转换成我需要的类形式。这就好比外国友人的电器插头不能适应我国。socket，那么就需要一个adapter，通过adapter插入我们的socket。其实上面的大学类就相当于这个适配器。我会通知负责这个类服务端开发的队友，他会按照这个类的形式重新组织要发送的JSON。而且我不需要再转换了。
