Head First Design Mode(9)-适配器模式与外观模式

该系列文章系个人读书笔记及总结性内容，任何组织和个人不得转载进行商业活动！

 

适配器模式与外观模式：  

    之前我们介绍过装饰者模式：它将对象包装起来，赋予他们新的职责；

    现在有不同的目的：包装某些对象，让他们的接口看起来不像自己而是别的东西；

    这样的设计，可以将类的接口转换成想要的接口，以便实现不同的接口；

    此外，本章我们还将讨论另外一种模式，将对象包装起来以简化其接口；

 

适配器场景举例：

    适配器将一种接口（三孔插座）转换成另一种接口（两孔插座）；

    

OO适配器和真实世界的适配器扮演者同样角色：将一个接口转换成另一个接口，以符合客户的期望；

 

面向对象适配器：

    已有一个软件系统，我们希望他能和一个新的厂商类库搭配使用，但是两者的接口无法匹配；

    我们不想改变现有的代码；

    可以写一个新类作为适配器：将客户所发出的请求转换成厂商类能理解的请求；

 

我们先看一个火鸡转换器：

    走起路像鸭子，叫起来像鸭子，可不一定真是一只鸭子，也有可能是一只包装了鸭子适配器的火鸡；

    我们定义鸭子接口 和 火鸡接口，通过具体的类实现相应的接口；

 

现在，我们缺鸭子对象，想用一些火鸡对象来冒充——写个适配器吧；

    接口Duck和Turkey定义了各自的行为；

    适配器实现了想转换成的类型接口，也就是客户期望看到的接口；

    适配器需要取得适配的对象的引用；

我们将火鸡包装进一个火鸡适配器中，使他看起来像是一只鸭子；

    测试时我们发现，虽然测试的都是鸭子，但是turkeyAdapter实际是一直火鸡；

 

 

适配器模式解析：

    目标接口：Duck

    被适配接口：Turkey

    被适配者：SubTurkey实例

    适配器：TurkeyAdapter

    客户：testDuck()

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

2）适配器使用被适配者接口把请求转换成被适配者的一个或多个接口；

3）客户接收到调用的结果，但未察觉这一切是适配器在起转换作用；

（客户和被适配者是解耦的，客户调用的是鸭子，被适配者实际是一只火鸡）

 

适配器模式的工作是将一个接口转换成另一个；

    如果让一个适配器包装多个被适配者，涉及到的是外观模式（Facade Pattern）；

 

定义适配器模式：

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

 

类图：

对象和类的适配器：

    实际上有两种适配器：对象适配器和类适配器；

    之前我们介绍的就是对象适配器；

 

类适配器：

    需要使用多继承才能够实现，如果使用Java是无法实现的；

    类适配器不是使用组合来适配被适配者，而是继承被适配者和目标类；

        

参照如下类图：

 

接下来，再看本章的另一个模式：

    适配器模式是将一个类的接口转换成另一个客户期望的接口；为此需要将一个不兼容接口的对象包装起来，变成兼容的对象；

    现在又一个改变接口的新模式，它改变接口的原因是为了简化接口——外观模式（隐藏复杂，显露干净美好的外观）；

 

装饰者：不改变接口，但加入责任；

适配者：将一个接口转成另一个接口；

外观：让接口更简单；

 

外观模式浅析：

    通过实现一个提供更合理的接口的外观类，你可以讲一个复杂的子系统变得容易使用；

    如果还需要使用复杂子系统的强大威力，还可以使用原有的复杂接口，但如果需要一个方便的接口，那就是外观；

 

这里：

    准备DVD和播放DVD都是外观类，他们对外暴露几个简单的方法；

    外观类将具体的诸多组件视作子系统，通过调用子系统来实现暴露的方法；

 

外观类只是提供更直接的操作，并未将原来的子系统阻隔起来；如果需要子系统类的更高层功能，还可以使用原来的子系统；

    外观没有封装子系统的类，只是提供了简化的接口，同时将客户从组件的子系统中解耦；

    一个子系统可以创建多个外观；

 

定义外观模式：

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

 

类图：

外观模式让客户与子系统之间避免紧耦合，也遵循了一个新的OO原则；

 

最少知识原则：

    只和你的密友谈话（较少对象间的交互，只留下几个密友）；    

 

不要让太多类偶合在一起，以免修改系统中一部分会影响到其他部分；

 

这个原则提供了一些方针：

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

1）该对象本身；

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

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

4）对象的任何组件；（成员变量）

如果某对象是调用其他的方法的返回结果，不要调用该对象的方法；

    

使用最少知识原则的缺点：

    导致更多的包装类被制造出来；

    复杂和开发时间页会增加，并降低运行时的性能；

 

外观和最少知识原则：

    为了符合最少知识原则 可以在子系统中使用更对外观 将子系统分成几个层次；

 

总结：

1.当需要使用一个现有的类而其接口并不符合你的需求时，就使用适配器；

2.当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观；

3.适配器改变接口以符合客户的期望；

4.外观将客户从一个复杂的子系统中解耦；

5.实现一个外观，需要将子系统组合进外观中，然后将工作委托给子系统执行；

6.可以为一个子系统实现一个以上的外观；

7.适配器将一个对象包装起来改变其接口；装饰者将一个对象包装起来以增加新的行为和责任；外观将一群对象“包装”起来以简化接口；

 

OO基础：

    抽象；

    封装

    继承；

    多态；

OO原则：

    封装变化

    多用组合，少用继承

    针对接口编程，不针对实现编程

    为交互对象之间的松耦合设计而努力；

    类应该对扩展开放，对修改关闭；

    依赖抽象，不要依赖具体类；

    ——只和朋友交谈（最少知识原则）；

OO模式：

    策略模式：定义算法族，分别封装起来，让他们之间互相替换，此模式让算法的变化独立于使用算法的客户；

    观察者模式：在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新；

    装饰者模式：动态地将责任附加到对象上；想要扩展功能，装饰者提供有别于继承的另一种选择；

    简单工厂模式；

    工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个；工厂方法让类把实例化推迟到子类；

    抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确具体的类；

    单件模式：确保一个类只有一个实例，并提供全局访问点；

    命令模式：将请求封装成对象，这可以让你使用不同的请求，队列或者日志请求来参数化其他对象；命令模式也支持撤销操作；

    ——适配器模式：将一个类的接口转换成客户期待的另一个接口，适配器让原来不兼容的类可以合作无间；

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