设计模式七之适配器模式和外观模式1

　　适配器模式转换接口，将原来两个不太适合的接口动作通过中间的接口给融洽在一起，从而共同操作，比如生活中得物理插座转换头等等。

　　在不同的接口之间进行适配经常是我们需要干得工作，于是设计模式给我们起了一个专用名词，适配器模式，使得两个不兼容的接口之间可以进行相互通信。外观模式则是把众多的接口进行把很多接口进行封装起来，组成一个更大的接口来进行协调，暴露给调用者，比较方便。

　　适配器模式有这么几个对象参与其中，客户、适配器、被适配者。客户是依据目标接口实现的，表现为Request。适配器实现了目标接口，并持有被适配者的实例，火鸡适配器实现了目标接口，并引用了一个被适配器，其表现为translatedRequest。火鸡就是被适配者，被适配接口是和目标接口不一样的。在这其中，含着一个过程，首先客户通过目标接口调用适配器的方法对适配器发出请求。然后适配器使用被适配者接口把请求转换成被适配者的一个或多个调用接口。最后客户接收到调用的结果，但并未察觉者一切是适配器在起转换作用。在这其中，客户和被适配者是解耦的，相互不用关心对方的接口。

　　适配器模式，将一个类的接口，转换成客户期望的另一个接口，适配器让原本接口不兼容的类可以合作无间。

　　这个模式可以通过创建适配器进行接口转换，让不兼容的接口编程兼容。这可以让客户从实现的接口解耦。如果一段时间之后，我们想要改变接口，适配器可以将改变的部分封装起来，客户就不必为了应对不同的接口而每次跟着修改。适配器实现了目标接口。所有的请求都委托给被适配者。

　　该模式充满着良好的OO设计原则：使用对象组合，以修改的接口包装被适配者；这种做法还有额外的优点，那就是，被适配者的任何子类，都可以搭配着适配器使用。可以看到，这个模式是如何把客户和接口绑定起来，而不是和实现绑定起来的。我们可以使用数个适配器，每一个负责转换不同组的后台类。或者，也可以加上新的实现，只要它们遵守目标接口就可以。

　　有两种适配器：对象适配器和类适配器。

　　类适配器需要多重继承才能够实现它，这在java中是不能实现的。类适配器不是使用组合来适配被适配者，而是继承被适配者和目标类。适配器继承了Target和Adaptee，而对象适配器利用组合的方式将请求传送给被适配者。

　　通过扩展两个类在一个类中，那么适配器使得火鸡可以响应对鸭子的请求，因为在一个类中。

　　适配器实现了鸭子的接口，但它收到方法调用时，会委托给火鸡。

　　当使用组合，不仅可以适配某个类，还可以适配该类的任何子类。

　　使用继承，只能够采用某个特定的被适配类。有一个比较大得优点就是，不需要重新实现整个被适配者。必要的时候，也可以覆盖被适配者的行为。

　　适配器模式的关键为找出适配者被适配者之间的方法映射关系。换句话说，我们要找出每一个适配器方法在被适配者中的对应方法是什么。

-------------------------------------------------------------------------------------------------------------------------------------------------

　　在改变接口的模式上面再抽象一层，改变接口的原因只是为了简化接口。于是就出现了一个新的模式，外观模式。之所以这么称呼，是因为它将一个或数个类的复杂的一切都隐藏在背后，只露出一个干净美好的外观。

　　考虑一种情况，组建一个家庭影院。尽量DIY。内含播放器、投影机、自动屏幕、环绕立体声，甚至还有爆米花机。全部搞定，但是有一天你回来，发现想马上看一部电影，但是每次总是忘记开一些装置，导致关于体验打折扣，每次中途去补。如果写成方法的调用，那么将涉及到多个不同的类。有了外观模式，可以把很多方法的调用组合在一起，一键解决。

　　外观没有“封装”子系统的类，外观只提供简化的借口。所以客户如果有必要，依然可以直接使用子系统的类。提供简化的接口的同时，依然将系统完整的功能暴露出来，以供需要的人使用。

　　想要使用外观模式，我们创建了一个接口简化而统一的类，用来包装子系统中一个或多个复杂的类。外观模式运行我们让客户和子系统之间避免紧耦合。

　　外观模式，定义：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。

　　提供一个简单地接口，好让一个子系统更易于使用。

　　其中蕴含了一个原则，最少知识原则。

　　最少知识(Least Knowledge)原则告诉我们要减少对象之间的交互，只留下几个"密友"。

　　最少知识原则：只和你得密友谈话。

　　当我们在设计一个系统，不管是任何对象，都要注意它所交互的类有哪些，并注意它和这些类是如何交互的。

　　这个原则希望我们在设计中，不要让太多的类耦合在一起，免得修改系统中一部分，会影响到其他部分。如果许多类之间相互依赖，那么这个系统就会变成一个易碎的系统，它需要花许多成本维护，也会因为太复杂而不容易被其他人了解。