java设计模式笔记之适配器模式

发布于 2018-01-14 10:58:06 | 108 次阅读 | 评论: 0 | 来源: 网友投递

这里有新鲜出炉的Java并发编程示例，程序狗速度看过来！

Java程序设计语言

适配器（Adapter）模式：

适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

生活中的场景：

1、笔记本电源适配器，可以将220v转化为适合笔记本使用的电压。

2、给笔记本电脑的usb接口插入台式机的ps/2接口的键盘，需要一个usb和ps/2的接口转接器，此时usb和ps/2的接口转接器就充当了适配器的角色。

通用类图：

　　在上面的通用类图中，Cient 类最终面对的是 Target 接口（或抽象类），它只能够使用符合这一目标标准的子类；而 Adaptee 类则是被适配的对象（也称 源角色），因为它包含specific （特殊的）操作、功能等，所以我们想要在自己的系统中使用它，将其转换成符合我们标准的类，使得 Client 类可以在透明的情况下任意选择使用 ConcreteTarget 类或是具有特殊功能的 Adaptee 类。

适配器模式中的角色：

目标接口(Target)：客户所期待得到的接口。目标可以是具体的或抽象的类，也可以是接口。
需要适配的类(Adaptee)：需要适配的接口或适配类。
适配器(Adapter)：适配器类是本模式的核心。适配器通过包装一个需要适配的对象，把源接口转换成目标接口。显然，这一角色不可以是接口，而必须是具体类。

适配器模式的结构：

适配器模式有类的适配器模式和对象的适配器模式两种不同的形式。

类的适配器模式把适配的类的API转换成为目标类的API。

对象的适配器模式与类的适配器模式一样，对象的适配器模式把被适配的类的API转换成为目标类的API，与类的适配器模式不同的是，对象的适配器模式不是使用继承关系连接到Adaptee类，而是使用委派关系连接到Adaptee类。

类的适配器模式

1、创建一个被适配的类：

/**
 * 被适配的类
 * 已存在的、具有特殊功能、但不符合我们既有的标准接口的类
 * (相当于例子中的，PS/2键盘)
 * @author ChuanChen
 * 
 */
public class Adaptee {

  public void specificRequest(){
    System.out.println("可以完成客户请求的需要的功能！");
  }
}

2、创建一个目标接口，能处理一些特殊请求

/**
 * 目标接口，或称为标准接口
 * @author ChuanChen
 *
 */
public interface Target {
  void handleReq();
}

3、创建一个适配器 (类适配器方式)

/**
 * 适配器 (类适配器方式)
 * (相当于usb和ps/2的转接器)
 * @author ChuanChen
 *
 */
public class Adapter extends Adaptee implements Target {


  @Override
  public void handleReq() {
    super.specificRequest();
  }
}

4、创建一个客户端

/**
 * 客户端类
 * (相当于例子中的笔记本，只有USB接口)
 * @author ChuanChen
 *
 */
public class Client {

  public void test(Target t){
    t.handleReq();
  }

  public static void main(String[] args) {
    Client c = new Client();
    Adaptee a = new Adaptee();
    Target t = new Adapter();
    c.test(t); 
  }  
}

　　上面这种实现的适配器称为类适配器，因为 Adapter 类既继承了 Adaptee （被适配类），也实现了 Target 接口（因为 Java 不支持多继承，所以这样来实现），在 Client 类中我们可以根据需要选择并创建任一种符合需求的子类，来实现具体功能。

对象的适配器模式

1、创建一个被适配的类：

/**
 * 被适配的类
 * 已存在的、具有特殊功能、但不符合我们既有的标准接口的类
 * (相当于例子中的，PS/2键盘)
 * @author ChuanChen
 * 
 */
public class Adaptee {

  public void specificRequest(){
    System.out.println("可以完成客户请求的需要的功能！");
  }
}

2、创建一个目标接口，能处理一些特殊请求

/**
 * 目标接口，或称为标准接口
 * @author ChuanChen
 *
 */
public interface Target {
  void handleReq();
}

3、创建一个适配器 (对象适配器方式,使用了组合的方式跟被适配对象整合)

/**
 * 适配器 (对象适配器方式,使用了组合的方式跟被适配对象整合)
 * (相当于usb和ps/2的转接器)
 * @author ChuanChen
 *
 */

public class Adapter implements Target{

private Adaptee adaptee;

  @Override
  public void handleReq() {
    adaptee.specificRequest();
  }

  public Adapter(Adaptee adaptee) {
    super();
    this.adaptee = adaptee;
  }

}

4、创建一个客户端

/**
 * 客户端类
 * (相当于例子中的笔记本，只有USB接口)
 * @author ChuanChen
 *
 */
public class Client {

  public void test(Target t){
    t.handleReq();
  }

  public static void main(String[] args) {
    Client c = new Client();
    Adaptee a = new Adaptee();
    Target t = new Adapter(a);
    c.test(t);
  }  
}

　　我们只需要修改 Adapter 类的内部结构，即 Adapter 自身必须先拥有一个被适配类的对象，再把具体的特殊功能委托给这个对象来实现。使用对象适配器模式，可以使得 Adapter 类（适配类）根据传入的 Adaptee 对象达到适配多个不同被适配类的功能，当然，此时我们可以为多个被适配类提取出一个接口或抽象类。这样看起来的话，似乎对象适配器模式更加灵活一点。

类适配器和对象适配器的权衡：

• 类适配器使用对象继承的方式，是静态的定义方式；而对象适配器使用对象组合的方式，是动态组合的方式。
• 对于类适配器，由于适配器直接继承了Adaptee，使得适配器不能和Adaptee的子类一起工作，因为继承是静态的关系，当适配器继承了Adaptee后，就不可能再去处理 Adaptee的子类了。
• 对于对象适配器，一个适配器可以把多种不同的源适配到同一个目标。换言之，同一个适配器可以把源类和它的子类都适配到目标接口。因为对象适配器采用的是对象组合的关系，只要对象类型正确，是不是子类都无所谓。
• 对于类适配器，适配器可以重定义Adaptee的部分行为，相当于子类覆盖父类的部分实现方法。
• 对于对象适配器，要重定义Adaptee的行为比较困难，这种情况下，需要定义Adaptee的子类来实现重定义，然后让适配器组合子类。虽然重定义Adaptee的行为比较困难，但是想要增加一些新的行为则方便的很，而且新增加的行为可同时适用于所有的源。
• 对于类适配器，仅仅引入了一个对象，并不需要额外的引用来间接得到Adaptee。
• 对于对象适配器，需要额外的引用来间接得到Adaptee。
  

建议尽量使用对象适配器的实现方式，多用合成/聚合、少用继承。当然，具体问题具体分析，根据需要来选用实现方式，最适合的才是最好的。

适配器模式的优点：

更好的复用性：

系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。　　

更好的扩展性：

在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。
适配器模式的缺点

过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。

适配器模式在工作中的场景：

1、已经存在的类的接口不符合我们的需求；
2、创建一个可以复用的类，使得该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作；
3、在不对每一个都进行子类化以匹配它们的接口的情况下，使用一些已经存在的子类。

适配器模式经常用于旧系统改造和升级。如果我们的系统开发之后再也不需要维护，那么很多模式都是没有必要的。但是不幸的是，事实上维护一个系统的代价往往是开发一个系统的数倍。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持PHPERZ。