Head First 设计模式之第七章——适配器模式与外观模式

适配器模式

适配器（Adapter)，顾名思义，即是通过转换接口，以达到匹配的目的。适配器模式也起到类似的作用。先举个例子，如下图所示，一个欧式的插座如何给美式的插头供电呢？答案很简单，添加一个交流电适配器即可，这个适配器一端连接欧式插座，另一端连接美式插头，插座与插头之间不需要相互认识，而只管给适配器供电与从适配器中获取电能即可。

在程序设计中，也常常存在这样的一个场景：假设已有一个软件系统，客户想让这个软件系统能与新的厂商类库搭配使用，但这个软件系统的接口只能与旧的厂商类库匹配而与新的厂商类库的接口不匹配，如下图所示。

当然，解决这个问题最直接粗暴的方法就是：要么修改现有的软件系统，要么要厂商修改类库，但这种方法成本较高，也显得十分的不优雅。此时可以在现有软件系统与新的厂商类库之间添加一个适配器类，将新厂商的接口转换到旧厂商的类库接口，如下图所示，那样现有的软件系统与新的厂商类库都不需要进行任何修改，即可进行搭配使用。

适配器模式的类图如下图所示：用户（Client）只依赖适配器接口，而适配器（Adapter）是适配器接口的具体实现，它可以将被适配者（Adaptee）的接口转换为适配器的接口。用户在使用时，可以直接调用适配器接口类型对象的request()方法，然后具体的适配器类就调用Adaptee的具体接口，响应用户发出的这个请求。用户只需要操作适配器接口即可，而不需要知道具体的被适配者是谁，用户与具体的Adaptee是完全解耦的。

但适配器模式可能存在的一个缺点就是：由于用户与Adaptee中增加了一个适配器，可能会降低整个系统的性能。

外观模式

外观模式这个名称初次听起来可能会让人摸不着头脑，但这其实是一个比较简单的设计模式。在讲述这个设计模式之前，可以先举个例子来更方便地理解这个模式。

现在很多人都爱好摄影，这其中的代表就是陈冠希老师啦。在摄影时，很多人都会选择使用单反相机，单反相机有手动模式与自动模式。当摄影师使用手动模式拍照时，他需要调整光圈、对焦、设置对比度等等的一系列操作，最后按下快门，完成照片的拍摄，手动模式对摄影师的要求较高，因为它要求摄影师熟悉每一个操作的细节，那样才能拍出一张像样的照片。然而，自动（auto）模式就不一样了，它只需要使用者先半按快门，相机就会自动完成对焦、调整光圈、设置对比度等的一系列操作，之后使用者再全按快门，即可完成整个拍摄过程，整个过程堪称无脑操作，或者是傻瓜式操作。

外观模式的作用就如上述相机的自动模式一样，它起到的作用就是简化接口，令使用者非常简单地调用这个接口从而实现自身目的，外观模式可以理解为一种傻瓜模式，为用户提供傻瓜式操作，而无需用户了解其中的实现细节，降低用户的使用负担。

外观模式的类图如下图所示，用户（Client）直接调用外观类（Facade）的接口，然后外观类封装了整个子系统的具体操作，外观模式很好地实现了用户与子系统之间的解耦，因为用户仅仅是依赖了外观类而已，如果以后想更换子系统，那用户类中的代码就不需要修改了。外观模式体现了面向对象设计中的一个重要原则——最少知识原则：“只和你的密码交谈”。什么意思呢？这个原则告诉我们，我们要减少对象之间的交互，只留下几个“密友”，即实现一个类时，要尽量减少这个类对其他类的依赖，依赖越少越好，从而减少耦合的，否则，如果耦合过多，一旦其中一个依赖类进行了修改，其它不少类都要进行相应的修改，那么这个系统是十分脆弱与不稳定的，也给代码的维护带来了很大的挑战。

适配器模式 VS 外观模式

适配器模式与外观模式虽然十分相似，但他们的目的是不相同的，

1. 适配器模式是为了转换接口，以让模式之间进行适应；
2. 外观模式是为了简化接口，好让用户理方便容易地调用这些接口，实现自己的目的。