👉 请投票支持这款 全新设计的脚手架 ，让 Java 再次伟大！
为什么要使用适配器设计模式
将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
适配器设计模式能够解决的问题，与现实生活中的适配器的用处基本上是一样的。
适配器设计模式怎么用
试想这样一种业务情况。
2001 年，你现在就职的公司为了负责开发了某著名游戏公司所设计的新游戏中的一个模块，而这个模块系统中有一个 duck 类，这个类与其它各种类被打包成 jar 提供给了游戏厂商的系统所使用。
/*** 适配器设计模式* 期望对象接口*/
public interface Duck {void quack();void fly();
}/*** 适配器设计模式* 期望对象*/
public class MallardDuck implements Duck {@Overridepublic void quack() {System.out.println("gua gua");}@Overridepublic void fly() {System.out.println("let me fly");}
}时过境迁，公司为了适应市场激烈的变化，推出了大量新产品，并设计了许许多多的其它的类。这些新设计的类，有些继承了 Duck 的结构，有些则是独立的、全新的类。比如下面这个全新的火鸡角色。
/*** 适配器设计模式* 被适配对象*/
public interface Turkey {void gobble();void fly();
}/*** 适配器设计模式* 被适配对象*/
public class WildTurkey implements Turkey {@Overridepublic void gobble() {System.out.println("gobble gobble");}@Overridepublic void fly() {System.out.println("let me fly");}
}为了让这款曾经的老游戏焕发新的活力。曾经的接口必需适应新产品的结构才行。要达到这样的目的，有两个方法
- 通知曾经的游戏厂商，为了我司全新的游戏产品重新设计游戏接口。
- 想办法让我司的新产品能够适应老旧的游戏厂商接口。
第一个方法显然是不现实的。所以，我们需要采用适配器设计模式，让它帮助我们使新产品能够运用到旧的接口上去。
适配器类要做的工作非常简单。持有被适配对象的引用，并实现期望对象接口就可以了。
/*** 适配器设计模式* 适配器对象*/
public class TurkeyAdapter implements Duck {private Turkey turkey;public TurkeyAdapter(Turkey turkey) {this.turkey = turkey;}@Overridepublic void quack() {turkey.gobble();}@Overridepublic void fly() {turkey.fly();}
}
通知厂商在新的游戏系统中加上全新的火鸡角色，让这款游戏变得更加丰富多彩。
/*** 适配器设计模式* 客户端*/
public class Client {private static Duck duck = new MallardDuck();public static void main(String[] args) {duck.fly();duck.quack();duck = new TurkeyAdapter(new WildTurkey());duck.fly();duck.quack();}
}let me fly
gua gua
let me fly
gobble obble
将上面的思路与代码做一下归纳与整理，适配器设计模式的类图也就迎刃而出了。最后通过 UML 类图再来加深一下对适配器设计模式的印象。
总结
适配器设计模式理解与运用上都比较简单。值得注意的是：适配器设计模式乍看起来与装饰器设计模式，但是这两个设计模式对应处理的是完全不同的问题。
装饰器设计模式的重点在于动态的为对象添加责任，并且被装饰对象的结构，接口必需与组件相同，并且在装饰过程中，被装饰对象与组建的接口不能发生变化。
而适配器设计模式的重点在于将不匹配的接口通过封装，将被适配对象的接口改变成为所期望的接口。
