设计模式总结之Bridge Pattern（桥接模式）

来源：互联网发布：陌生人视频聊天软件编辑：程序博客网时间：2024/06/05 17:42

转自：http://blog.csdn.net/cooldragon/article/details/52173915

Bridge Pattern（桥接模式）

意图

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

【GOF95】在提出桥梁模式的时候指出，桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。这句话有三个关键词，也就是抽象化、实现化和脱耦。

* 抽象化
存在于多个实体中的共同的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当做同样的实体对待【LISKOV94】。
* 实现化
抽象化给出的具体实现，就是实现化。
* 脱耦
所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。

将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的用意。

结构

桥梁模式所涉及的角色有：
抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。

例子

一个表就一个表带？

还是，一个表+多个可更换的表带？

桥接模式和适配器模式的区别

很多时候经常容易把桥接模式和适配器模式弄混。那什么时候用桥接，什么时候用适配器呢？

共同点：
桥接和适配器都是让两个东西配合工作

不同点：出发点不同。
　　适配器：改变已有的两个接口，让他们相容。
　　桥接模式：分离抽象化和实现，使两者的接口可以不同，目的是分离。

所以说，如果你拿到两个已有模块，想让他们同时工作，那么你使用的适配器。如果你还什么都没有，但是想分开实现，那么桥接是一个选择。

桥接是先有桥，才有两端的东西适配是先有两边的东西，才有适配器。
桥接是在桥好了之后，两边的东西还可以变化。

桥模式并不同于适配器模式，适配器模式其实是一个事后诸葛亮，当发现以前的东西不适用了才去做一个弥补的措施。桥模式相对来说所做的改变比适配器模式早，它可以适用于有两个甚至两个以上维度的变化。

桥接模式将继承关系转换为关联关系，从而降低了类与类之间的耦合，减少了代码编写量。

理解二：

生活中的一个例子:
拿汽车在路上行驶的来说。既有小汽车又有公共汽车，它们都不但能在市区中的公路上行驶，也能在高速公路上行驶。这你会发现，对于交通工具（汽车）有不同的类型，它们所行驶的环境（路）也有不同类型，在软件系统中就要适应两个方面（不同车型，不同道路）的变化，怎样实现才能应对这种变化呢？
概述:
在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
意图:
　　　将抽象部分与实现部分分离，使它们都可以独立的变化。
——《设计模式》GOF

上面这些话我也没看懂。。太抽象了，但是一看代码你就明白是怎么回事了。
结构图:

传统的做法:
通过类继承的方式来做上面的例子;
先看一下类结构图:

代码实现：

[java] view plain copy
 print?
        //基类 路  
class Road {  
    void run() {  
        System.out.println("路");  
    }  
}  
  
//市区街道  
class Street extends Road {  
    void run() {  
        System.out.println("市区街道");  
    }  
}  
  
//高速公路  
class SpeedWay extends Road {  
    void run() {  
        System.out.println("高速公路");  
    }  
}  
//小汽车在市区街道行驶  
class CarOnStreet extends Street {  
    void run() {  
        System.out.println("小汽车在市区街道行驶");  
    }  
}  
//小汽车在高速公路行驶  
class CarOnSpeedWay extends SpeedWay {  
    void run() {  
        System.out.println("小汽车在高速公路行驶");  
    }  
}  
//公交车在市区街道行驶  
class BusOnStreet extends Street {  
    void run() {  
        System.out.println("公交车在市区街道行驶");  
    }  
}  
//公交车在高速公路行驶  
class BusOnSpeedWay extends SpeedWay {  
    void run() {  
        System.out.println("公交车在高速公路行驶");  
    }  
}  
//测试  
public static void main(String[] args) {  
      
    //小汽车在高速公路行驶  
    CarOnSpeedWay carOnSpeedWay = new CarOnSpeedWay();  
    carOnSpeedWay.run();  
    //公交车在市区街道行驶  
    BusOnStreet busOnStreet = new BusOnStreet();  
    busOnStreet.run();  
  
}  

缺点:
但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起变化的原因却有两个，即路类型的变化和汽车类型的变化；其次是重复代码会很多，不同的汽车在不同的路上行驶也会有一部分的代码是相同的；

再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化，我们会看到这个类的结构会迅速的变庞大。

应用设计模式
桥接模式（Bridge）来做;
先看一下类结构图:

代码实现：

[java] view plain copy
 print?
abstract class AbstractRoad{  
    AbstractCar aCar;  
    void run(){};  
}  
abstract class AbstractCar{  
    void run(){};  
}  
  
class Street extends AbstractRoad{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        aCar.run();  
        System.out.println("在市区街道行驶");  
    }  
}  
class SpeedWay extends AbstractRoad{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        aCar.run();  
        System.out.println("在高速公路行驶");  
    }  
}  
class Car extends AbstractCar{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        System.out.print("小汽车");  
    }  
}  
class Bus extends AbstractCar{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        System.out.print("公交车");  
    }  
}  
  
public static void main(String[] args){  
      
    AbstractRoad speedWay = new SpeedWay();  
    speedWay.aCar = new Car();  
    speedWay.run();  
      
    AbstractRoad street = new Street();  
    street.aCar = new Bus();  
    street.run();  
}  

可以看到，通过对象组合的方式，Bridge 模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。
      这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。
应用设计模式:
       桥接模式（Bridge）来做(多维度变化);
       结合上面的例子,增加一个维度"人",不同的人开着不同的汽车在不同的路上行驶(三个维度);
       结合上面增加一个类"人",并重新调用.
代码实现:

[java] view plain copy
 print?
abstract class People {  
    AbstractRoad road;  
  
    void run() {}  
}  
  
class Man extends People{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        System.out.print("男人开着");  
        road.run();  
    }  
}  
class Woman extends People{  
    @Override  
    void run() {  
        // TODO Auto-generated method stub  
        super.run();  
        System.out.print("女人开着");  
        road.run();  
    }  
}  
  
public static void main(String[] args) {  
  
    AbstractRoad speedWay = new SpeedWay();  
    speedWay.aCar = new Car();  
      
    People man = new Man();  
    man.road = speedWay;  
    man.run();  
}  

效果及实现要点：
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同路上的不同汽车。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。

适用性：
在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
总结：
Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。

作者：jason0539

微博：http://weibo.com/2553717707

博客：http://blog.csdn.net/jason0539（转载请说明出处）

0 0

设计模式总结之Bridge Pattern（桥接模式）

目录

Bridge Pattern（桥接模式）

意图

结构

例子

桥接模式和适配器模式的区别