目录：
1. 生活中的适配器；
2. 代码实现简单的适配器模式；
3. 适配器模式定义及解析；
4. 适配器模式的两种结构
5. 枚举器和迭代器的适配
6. 外观模式引出；
7. 外观模式的定义及解析；
8. “最少知识原则”；
9. 适配器模式、外观模式以及装饰者模式之间的区别。
1. 生活中的适配器
上图，中间的适配器改变了插座的接口，最后成功让电脑能够使用充电。
接下来让我们看看，现有系统、适配器和厂商类之间的关系。
2. 代码实现简单的适配器模式；
下面举出一个例子，来展示简单的适配器模式。
3. 适配器模式定义及解析；
适配器模式定义：将一个类的接口，转换成客户期望的另一个接口。适配器让原来接口不兼容的类可以合作无间。
客户调用适配器的步骤如下：
a. 客户通过目标接口调用适配器的方法，对适配器发出请求；
b. 适配器使用被适配器者接口把请求转换成被适配者的一个或多个调用接口；
c. 客户接收到调用的结果，但并未察觉这一切是适配器在起转换作用。
注意：适配器一般只封装一个类，封装多个类称为外观模式（其实两者还有不同点，暂时先这么理解）。
双向适配器：实现两个接口，可以被新旧客户一起使用而不冲突。
4. 适配器模式的两种结构
适配器有两种结构，分别是对象适配器和类适配器（java不能用）
对象适配器
对象适配器有如下优点：
a. 被适配者的任何子类，都可以搭配着适配器使用；
b. 客户是和接口所绑定起来的而不是和实现绑定起来的，所以我们可以使用数个适配器，每一个适配器都负责转换不同组的后台类。
类适配器
、
多重继承（java用不上），然后利用多态的性质，将客户对Target的调用直接转到adaptee的方法上面。
两者之间的区别：
a. 对象适配器，可以适配某个类，也可以适配该类的子类；
b. 类适配器：必要时可以覆盖被适配者的行为且不需要重新实现被适配者（对象适配器需要重新实现被适配者，比如之前的火鸡案例）。
5. 枚举器和迭代器案例
6. 外观模式引出：将一个或数个类的复杂的一切都隐藏在背后，只显露出一个干净美好的外观；
关于外观模式的问题：
a. 如果外观封装了子系统的类，那么需要低层功能的客户如何接触这些类？
外观没有“封装”子系统的类，外观只提供简化的接口。客户如果有需要，可以直接使用子系统的类。这也是外观模式很好的特征：提供简化的接口的同时，依然将系统完整的功能暴露出来，供需要的人使用。
b. 每个子系统只有一个外观吗？
不，可以为一个子系统创建多个外观。
c. 除了提供简单接口之外，外观模式还有其他优点吗？
如果我们需要升级家庭影院，我们根本不需要修改客户的代码，而直接修改外观的代码。成功的将客户从子系统中解耦出来。
我们编写一下家庭影院的代码，很简单。
7. 外观模式的定义及解析；
外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。（目的）外观定义了一个高级接口，让子系统更容易使用。
8. “最少知识原则”；
最少知识原则：减少对象之间的交互，只留下几个密友，只和密友谈话。
这是什么意思呢？
这个原则希望我们在设计中，不要让太多的类耦合在一起，免得修改系统中的一部分，会影响到其他部分。如果许多类之间相互依赖，那么这个系统就会变成一个易碎的系统，需要花许多成本维护，也会因为太复杂而不容易被其他人了解。
究竟怎样才能避免太多耦合呢？
该原则提供了一些方针，就任何对象而言，在该对象的方法内，我们只应该调用属于以下范围的方法：
a. 该对象本身的方法；
b. 被当成方法的参数而传递进来的对象；
c. 此方法所创建或实例化的任何对象；
d. 对象的任何组件（实例化变量所引用的任何对象）。
上面方针告诉我们：如果某对象是调用其他方法返回的结果，不需要调用该对象的方法。
例子如下：
优点：减少了对象之间的依赖，减少了软件的维护成本。
缺点：这个原则会导致更多地“包装”被制造出来，以处理和其他组件的沟通，可能会导致复杂度和开发时间的增加，并降低运行时的性能。
总结所有：
9. 适配器模式、外观模式以及装饰者模式之间的区别。
区别：适配器将一个对象包装起来以改变其接口；装饰者将一个对象包装起来以增加新的行为和责任（装饰对象还是用的相同的接口）；外观将一群对象包装起来以简化其接口。
适配器其实也可以和外观一样包装多个类，适配器的主要意图是将接口转换为不同的接口，外观模式的的意图是简化接口，装饰者模式的意图是拓展包装的对象的行为或者责任。