它有啥用？

包裹一些对象，让它们看起来不像它们，而像别的东西。
这个模式实现的功能是把一个接口应用于一个适用于另一个接口的类。
该模式能通过包裹对象的方式来简化接口。
这个模式的中文名称应该叫啥呢？我不想翻译得太机械。
P248的图非常形象地解释了这个模式——这个模式就是提供了一个中间层和转换器的功能。
所以这个模式应该翻译成适配器和外观模式。

什么是适配器模式？

整个适配器模式的逻辑结构就是P253所表示的那样。
客户按照目标接口的标准来实现，适配器也按照目标接口的标准来实现的，但是目标是按照目标的接口来实现的。那么适配器和目标的接口标准不同，它们是怎么相互对接的呢？原来适配器的实现里面复合地包含了一个目标的实例对象在里面。我想这个目标接口应该就是与目标相适配的接口，如果拿插头和插座来比拟的话，就应该是能够插进某个插座的插头类型。

它的一般流程

1、因为客户和适配器都实现了相同的目标接口，所以客户可以调用目标接口中的方法向适配器发送一个请求。
2、适配器接收到来自客户的请求就把它们转化成一个或多个目标所能接受的请求。
3、在此过程中目标和客户都不知道适配器的存在。

适配器的精髓

适配器模式的核心就是把一个接口转换成另一个接口。
适配器模式只包含一个目标接口实例。
适配器模式可以通过实现多个接口来实现来充当多功能适配器。

Adapter Pattern defined

它把一个接口转换成客户所需要的接口，该模式可以让那些原本因为不兼容而无法协同使用的类共同协作。
P255的类图清晰地显示了该模式的逻辑组织。

Object and class adapters

其实，适配器模式分为两种，一个叫对象适配器，另一个叫类适配器。
以前讲的都是对象适配器模式，现在要讲的是类适配器模式。
之所以在前面作者没有提到是因为，类适配器模式需要多重继承，而JAVA不支持多重继承，但是C++可以。
与对象适配器模式不同的是，类适配器模式使用的是继承而不是复合，P256的类图非常清晰地说明了这一点。
适配器是通过同时继承目标类和被适配类的方式来达到二者的兼容的，而对象适配器是通过复合被适配类的对象来达到此目的的。

它俩各自的优劣

对象适配器模式不仅可以适配某一个类而且能适配它所有的子类类型，而类适配器模式则不行，但是它能重写被适配类的某些方法，因为它是继承。
由于前者使用的是复合因此其灵活性很好，但是因为后者用的是继承，所以后者的效率较高，因为无论是适配还是被适配都是一个类。

Real world adapters

从这段描述可以看出适配器模式可以解决新旧版本代码过渡的问题，添加个中间层完美地完成过渡。
P261中的虚箭头代表继承，实箭头代表复合，反正这是我猜的。

装饰者模式和适配器模式的区别

装饰者模式是不断地滚雪球，不断地增加功能，而适配器模式只是个中间层，转换器。
装饰者模式的耦合度比适配器模式要大。
装饰者模式不转换接口，而适配器模式转换接口。
装饰者模式侧重于功能的扩展，而适配器模式侧重于功能的转换。

The Façade Pattern

外貌模式旨在屏蔽一个或多个类的复杂性，而流出一个简单的接口出来，它的意义就在于简化接口复杂性。
怎么说呢，我们做一件事总希望一步搞定，但实际上一件事涉及到很多琐碎的细节，这些细节都是我们不想搭理的，那么外貌模式可以来处理这些细节让我们的操作更加方便。
外观模式可以让你接受一个复杂的系统，并通过实现一个外观类，从而向外界提供一个或多个接口的来简化使用。
那个外观类就像一个遥控器，那个系统就负责完成遥控器上的功能。
外观模式的作用不仅仅是简化一个接口那么简单，而是把用户和具体的子系统的耦合解开。
外观模式不是封装了一个大型的功能，它只是提供了一个接口而已，你仍然可以去访问那个系统，去使用你想用的更加具体的功能。
外观模式并没有增加新的行为，但是它足够智能地控制这些行为，就是能实现自动化。
适配器模式的作用是要去改变一个接口以适应用户的需求，而外观模式是提供了一个简化的接口给用户。
一个系统可能有n个外观接口。
P274内容把接口的内部实现细节展现了出来，其实很简单，就是按顺序把各个方法罗列出来就好了。

Facade Pattern defined

针对于一个子系统的若干个接口提供一个统一的接口。外观模式定义了一种更高层次的接口，它使子系统更加方便使用。

The Principle of Least Knowledge原则

“只与直接朋友对话”。
这个原则的意思是尽量减少对象之间的互动，只与极为有限的几个“伙伴”保持联系。
它提醒你要注意互动的类的个数以及方式。

How NOT to Win Friends and Influence Objects原则

这个原则告诉我们应该调用归属于如下4个方面的方法：
1、本对象。
2、以该对象为参数的方法。
3、属于本方法所创建或实例化的对象的方法。
4、该对象的任何组件的方法。
这4个方面说明不要调用从其他方法返回的对象的方法，如果你确实这样做了，那就意味着你在和另外一个对象某部分发生依赖，这就增加了有关联的对象的数量，这不符合原则。如果这种情况无法避免，我们会让那个对象为我们完成需求。
虽然这个做法的精髓我还不太理解，但是看P278的例子，我稍微明白好像就是避免自己创建对象，能直接用别人的就直接用别人的。

Keeping your method calls in bounds...

P279具体地说明你可以调用哪些方法，这是很好的例子。
the Principle of Least Knowledge的缺点：它导致了更多的包装类 ，它们负责控制对其他组件的调用，这会导致复杂性的增加和开发时间的增长。
The Facade and the Principle of Least Knowledge
不管怎样，外观模式始终只有一个面向用户的接口，其下有很多子类，每个子类发生更改并不影响其他，这很符合Least Knowledge原则。
但是子系统实在过于复杂的话，你可以有多于一个的接口。