设计模式 之桥接模式

以前说过的翻译计划食言了。如今开始翻，从 结构型设计模式 桥接模式开始，由于以前的都在github上写过了（稍后记得整理下）。

如今主流的设计模式主要分三大类

建立型设计模式，结构型设计模式，行为型设计模式。

建立型设计模式：

工厂方法模式 抽象工厂模式 原型链模式 单例模式 建造者模式 对象池模式

结构型设计模式：

适配器模式 桥接模式  复合模式 装饰模式 外观模式 享元模式 私有类数据模式 代理模式

行为型设计模式：

责任链模式 命令模式 解释器模式 策略模式 访问者模式 迭代模式 观察者模式 备忘录模式 模板方法模式 空对象模式 中介者模式 状态模式

桥接模式

目的

• 解耦抽象类的实现，使二者独立出来。

• 在层里添加一个接口,销毁对本身的子层的实现。

• 封装的背后，是为了更好的隔离。

问题

    "增强软件的主线"已经经过使用一个抽象基类的子类提供不一样的实现。编译绑按期间它会在接口和实现之间加锁。使抽象类和接口不能单独扩展或组合。

动机
想象一下线程调度器

假设如今有两种线程调度器，两种操做系统或平台。咱们该如何给它分类呢，咱们必须得给这两种类型下的每种可能都新增一个类。若是咱们新增了一个平台（好比说java的虚拟机），那么如今咱们的系统看起来怎么样呢？

假设咱们有三种线程调度器，四种平台，会怎样？再假设咱们有五种线程调度器，十种平台，又会怎样？咱们要定义的对象数量是由调度器的数量和平台的数量决定的。

桥接模式旨在重构两个垂直层之间指数级增加的子类-----一个是为了平台独立的抽象，一个是为了平台依赖的实现。

 

讨论
分解组件的接口和实现为两个垂直的类层。接口类包含了一个pointer对抽象实现的类。这个pointer初始化为 一个具体实现类的实例化, 可是后面全部的交互从接口类到实现类都被限制在包含在实现基类里的抽象类里。客户端和接口类交互, 它把全部"表明"的请求转化为实现类。

接口对象是一个被客户端使用的把手; 当实现对象或者"主体"，被安全地封装以确保它可能被继续使用，或被替换(又或在运行期间被分享出去)。
以下为可能使用桥接模式的条件：
    你想动态绑定实现类
    由于接口过多和大量的实现致使类的数量剧增
    想在多个对象中分享一个实现
    想构建垂直不相关的类层
这样作的好处:
    解耦了类的接口
    提高可扩展性
    对客户端隐藏实现细节(能够各自扩展子类的抽象类和接口类)

桥接是"把手/主体"的近义词。这种设计模式在接口类的内部封装了实现类。前者是主体,后者是把手。把手是用户能看到的类，可是在主体内部运行。"桥接模式吧一个复杂的抽象类分解的更小，更容易管理。名字也反映了多个能够操做它的类分享了单一资源（这翻的有点拗口）"

未完待续