Head First 设计模式--Adaptor & Facade

Chapter 7 --适配器模式和外观模式

                                   随遇而安

 

1. 适配器实现了目标接口，并且引用一个被适配者。

 

2. 客户使用适配器的过程:

(1) 客户通过目标接口调用适配器的方法对适配器发出请求。

(2) 适配器使用被适配者接口把请求转换成被适配者的一个或多个调用接口。

(3) 客户收到调用的接口，但并未察觉这一切是适配器在起转换作用。

 

3. 实现一个适配器所需要进行的工作，和目标接口的大小成正比。为了避免改写客户端的代码来调用新的接口，提供一个适配器类，来将所有的改变封装在一个类中是一个比较好的做法。

 

4. 可以创建一个双向的适配器，同时支持新的接口和旧的接口，但是它必须实现所涉及的两个接口。

 

 

适配器模式：

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

 

Structure

• Client: 客户只看到目标接口。
• Adapter: 适配器实现目标接口。适配器与被适配者组合。
• Adaptee: 所有的请求都委托给被适配者。

 

5. 适配器模式充满了良好的OO设计原则：使用对象组合，以修改的接口包装被适配者。此外，被适配者的任何子类都可以搭配着适配器使用。

 

6. 对象适配器利用组合的方式将请求传送给被适配者，而类适配器继承被适配者和目标类（多重继承）。

 

 

 

7. 装饰者模式的意图是不改变接口，但加入责任。适配器模式的意图是将一个接口转成另一个接口。外观模式的意图是简化接口。外观和适配器都可以包装许多类，但它们的区别在于意图不同。

 

8. 外观模式有一个很好的特征：提供简化的接口的同时，依然将系统完整的功能暴露出来，以供需要的人使用。外观没有“封装”子系统的类，它只提供简化的接口。如果客户觉得有必要，依然可以直接使用子系统的类。

 

9. 外观不只是简化了接口，也将客户从组件的子系统中解耦。

 

 

外观模式：

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

 

Structure

• Client: 因为有了外观，客户的工作变得更容易了。
• Facade: 统一的接口易于使用。
• Subsystem classes: 更复杂的子系统。

 

设计原则：

 

(1) 最少知识(Least Knowledge)原则：只和你的密友谈话。

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

 

就任何对象而言，在该对象的方法内，我们只应该调用属于以下范围的方法：

(1) 该对象本身

(2) 被当做方法的参数而传递进来的对象

(3) 此方法所创建或实例化的任何对象

(4) 对象的任何组件

 

不要调用从另一个调用中返回的对象的方法，如果这样做，相当于向另一个对象的子部分发请求（而增加我们直接认识的对象数目）。该原则要我们改为要求该对象为我们做出请求，这样就不需要认识该对象的组件了。

 

 

本章小结：

• 当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器。
• 当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观。
• 适配器改变接口以符合客户的期望。
• 外观将客户从一个复杂的子系统中解耦。
• 实现一个适配器可能需要一番功夫，也可能不费功夫，视目标接口的大小与复杂度而定。
• 实现一个外观，需要将子系统组合进外观中，然后将工作委托给子系统执行。
• 适配器模式有两种形式：对象适配器和类适配器。类适配器需要用到多重继承。
• 你可以为一个子系统实现一个以上的外观。
• 适配器将一个对象包装起来以改变其接口；装饰者将一个对象包装起来以增加新的行为和责任；而外观将一群对象“包装”起来以简化其接口。