设计模式学习笔记（十六：桥接模式）

1.1概述

    将抽象部分与它的实现部分分离，使他们都可以独立地变化。这就是桥接模式的定义。

    抽象类或接口中可以定义若干个抽象方法，习惯上将抽象方法称作操作。抽象类或接口使程序的设计者忽略操作的细节，即不必考虑这些操作是如何实现的，当用户程序面向抽象类或接口时，就不会依赖具体的实现，使系统具有很好的扩展性。但是，抽象类中的抽象方法总归是需要子类去实现的，在大多数情况下抽象类的子类完全可以胜任这样的工作，但是在某些情况下，子类可能会遇到一些难以处理的问题。

  例如，电视台系统中有一个抽象类CCTV，该类有一个抽象方法abstract void makeProgram()。现在为了满足某些用户看电视剧的需求，这里给出了CCTV类的子类：CCTV8，该类的实例调用makeProgram()方法制作电视剧节目，因此子类CCTV8必须实现父类的makeProgram()方法，比如使用该方法制作出若干帧影像。子类CCTV8的makeProgram()方法在制作出第一帧影像后，比如在第一帧影像显示“CCTV8”，马上就发现以下两个问题：

（1）从第2帧开始应当是电视剧中的影像，而这样的影像不应当由CCTV8类的makeProgram()方法负责制作。

（2）如果CCTV8在makeProgram()方法中强行给出了第2帧以后的各个影像，那么用户使用CCTV8类的实例看到的电视剧是一个固定的电视剧，如果有其他用户想看新的电视剧，系统就必须新增新的CCTV子类，这对电视台系统是一个非常不合理的一种设计，因为CCTV类应当只有一个负责制作“电视剧”节目的子类：CCTV8，而不是多个，也就是说，不能因为一个新的用户要看不同的电视剧，就要出现一个专门为该用户制作“电视剧”节目的子类。

  针对上述问题，应当将实现和抽象放在两个不同的类层次中，从而使他们可独立的改变，即将一个抽象类中抽象方法的重要实现部分交给另外一个抽象类的子类或实现另外一个接口的类。比如，对于上述问题，应当将makeProgram()方法的实现交给另外一个抽象类：Program，该类定义了制作影像的makeTVfilm()方法。

  我们应当重新设计抽象类CCTV类，使该类包含Program的引用，这就可以使CCTV类的子类CCTV8在实现makeProgram()方法时，将该方法的重要实现部分交给Program类的makeTVfilm()方法，即委托给Program子类的实例调用makeTVfilm()方法。

  我们称CCTV类和Program类之间的关系是桥接关系，也即是说，CCTV类的子类CCTV8仅仅在CCTV类和Program类之间起到一个“桥接”的作用，具体类关系如下图一所示：

 

图一：电视节目与电视剧制作的桥接关系

 

 

1.2模式的结构

桥接模式包括以下四种角色：

（1）抽象（Abstration）：是一个抽象类，该抽象类含有Implementor声明的变量，即维护一个Implementor类型对象。

（2）实现者（Implementor）：实现者角色是一个接口（抽象类），该接口（抽象类）中的方法不一定与Abstration类中方法一致。Implementor接口（抽象类）负责定义基本操作，而Abstration类负责定义基于这些基本操作的较高层次的操作。

（3）细化抽象（Refined Abstration）：细化抽象是抽象角色的一个子类，该子类在重写（覆盖）抽象角色中的抽象方法时，在给出一些必要的操作后，将委托所维护Implementor类型对象调用相应的方法。

（4）具体实现者（Concrete Implementor）：具体实现者是实现（扩展）Implementor接口（抽象类）的类。

桥接模式结构的类图如下图二所示：

 

图二：桥接模式的类图

 

1.3桥接模式的优点

（1）桥接模式分离实现与抽象，使抽象和实现可以独立的扩展。当修改实现的代码时，不影响抽象的代码，反之也一样。

（2）满足开-闭原则。抽象和实现者处在同层次，使系统可独立地扩展者两个层次。增加新的具体实现者，不需要修改细化对象，反之增加新的细化对象也不需要修改具体实现。

 

1.4适合使用桥接模式的情景

（1）不想让抽象和某些重要的实现代码是固定绑定关系，这部分实现可运行时动态决定。

（2）抽象和实现者都可以继承的方法独立地扩充而互不影响，程序在运行期间可能需要动态的将一个抽象的子类的实例与一个实现者的子类的实例进行组合。

（3）希望对实现者层次的代码的修改对抽象层不产生影响，即抽象层的代码不必重新编译，反之亦然。