一、适配器模式介绍:
由于应用环境的变化,我们需要的实现在新的环境中没有现存对象可以满足,但是其他环境却存在这样现存的对象。适配器模式将“将现存的对象”在新的环境中进行调用,使得新环境中不需要去重复实现已经存在了的实现而很好地把现有对象(指原来环境中的现有对象)加入到新环境来使用。适配器模式有类的适配器模式和对象的适配器模式两种形式。
二、实现思维:
在适配器模式中,适配器可以是抽象类,并适配器模式的实现是非常灵活的,我们完全可以将Adapter模式中的“现存对象”作为新的接口方法参数,适配器类可以根据参数参数可以返回一个合适的实例给客户端。把一个类的接口变换成客户端所期待的另一种接口,从而使原本接口不匹配而无法一起工作的两个类能够在一起工作。
三、情景例子:
在当今社会手机已经是人们生活中必不可少的东西,就像人要吃饭,手机当然也要充电,相信很多苹果手机用户都遇到过手机没电时没带充电线,找别人借却只有安卓的充电线,这就很尴尬了。那么如何用适配器模式解决这个问题呢?让我们来看看下面的代码。
四、类的适配器相关代码:
1、创建适配器类——安卓插头
/// <summary> /// 适配器模式中的源角色,需要适配的类,安卓插头 /// </summary> public abstract class AndroidPlug { public void SpecificRequest() { Console.WriteLine("我是安卓插头"); } }
2、创建苹果插头的接口:
/// <summary> /// 适配器模式中的目标角色,苹果插头 /// </summary> public interface IApplePlug { void Request(); }
3、创建适配器类,提供苹果插头,实现安卓插头方法:
/// <summary> /// 适配器类,提供苹果插头行为,但本质是调用安卓插头方法 /// </summary> public class AdapterPlug : AndroidPlug, IApplePlug { /// <summary> /// 实现安卓插头方法 /// </summary> public void Request() { //调用安卓插头方法 this.SpecificRequest(); } }
4、调用
static void Main(string[] args) { //现在可以通过适配器使用安卓插头了 IApplePlug apple_plug = new AdapterPlug(); apple_plug.Request(); Console.ReadKey(); }
从上面代码中可以看出,我们调用Request方法(即苹果插头),但是我们现有的类(即安卓插头)并没有Request方法,它只有SpecificRequest方法(即安卓插头本身的方法),然而适配器类(适配器必须实现苹果插头接口和继承安卓插头类)可以提供这种转换,它提供了Request方法的实现(其内部调用的是安卓插头,因为适配器只是一个外壳罢了,包装着安卓插头,并向外界提供苹果插头的外观,)以供我们使用。这可以结合现有的苹果安卓一体充电线实体理解。
五、对象适配器:
既然现在适配器类不能继承AndroidPlug抽象类了(因为用继承就属于类的适配器了),但是适配器类无论如何都要实现Request方法,所以一定是要继承ApplePlug抽象类或IApplePlug接口的,然而适配器类的Request方法又必须调用AndroidPlug的SpecificRequest方法,又不能用继承,这时候就想,不能继承,但是我们可以在适配器类中创建AndroidPlug对象,然后在Requst中使用AndroidPlug的方法了。
六、对象适配器相关代码:
1、创建源角色,安卓插头类
/// <summary> /// 适配器模式的源角色,需要适配的类,安卓插头 /// </summary> public class AndroidPlug { public void SpecificRequest() { Console.WriteLine("我是安卓插头"); } }
2、创建目标角色,苹果插头类:
/// <summary> ///适配器模式中的目标角色,苹果插头 /// </summary> public class ApplePlug { // 客户端需要的方法 public virtual void Request() { // 可以把一般实现放在这里 } }
3、创建适配器类:
/// <summary> /// 适配器类,这里适配器类没有AndroidPlug类,而是引用了AndroidPlug对象,所以是对象的适配器模式的实现 /// </summary> public class Adapter : ApplePlug { // 引用安卓插头的实例,从而将客户端与AndroidPlug系起来 public AndroidPlug android_plug_Adapter = new AndroidPlug(); /// <summary> /// 实现苹果插头接口方法 /// </summary> public override void Request() { android_plug_Adapter.SpecificRequest(); } }
4、调用
static void Main(string[] args) { // 现在可以通过适配要使用安卓插头了 ApplePlug apple_plug = new Adapter(); apple_plug.Request(); Console.ReadLine(); }
七、使用情景:
- 系统需要复用现有类,而该类的接口不符合系统的需求
- 想要建立一个可重复使用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作。
- 对于对象适配器模式,在设计里需要改变多个已有子类的接口,如果使用类的适配器模式,就要针对每一个子类做一个适配器,而这不太实际。
八、总结:
类的适配器模式:
优点:
- 可以在不修改原有代码的基础上来复用现有类,很好地符合开闭原则。
- 可以重新定义Adaptee(被适配的类)的部分行为,因为在类适配器模式中,Adapter是Adaptee的子类
- 仅仅引入一个对象,并不需要额外的字段来引用Adaptee实例(这个即是优点也是缺点)。
缺点:
- 用一个具体的Adapter类对Adaptee和Target进行匹配,当如果想要匹配一个类以及所有它的子类时,类的适配器模式就不能胜任了。因为类的适配器模式中没有引入Adaptee的实例,光调用this.SpecificRequest方法并不能去调用它对应子类的SpecificRequest方法。
- 采用了 “多继承”的实现方式,带来了不良的高耦合。
对象的适配器模式
优点:
- 可以在不修改原有代码的基础上来复用现有类,很好地符合开闭原则
- 采用 “对象组合”的方式,更符合松耦合。
缺点:
- 使得重定义Adaptee的行为较困难,这就需要生成Adaptee的子类并且使得Adapter引用这个子类而不是引用Adaptee本身。