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

不少时候常常容易把桥接模式和适配器模式弄混。那何时用桥接，何时用适配器呢 ？

共同点：桥接和适配器都是让两个东西配合工做
不一样点：出发点不一样。
         适配器：改变已有的两个接口，让他们相容。
         桥接模式：分离抽象化和实现，使二者的接口能够不一样，目的是分离。

因此说，若是你拿到两个已有模块，想让他们同时工做，那么你使用的适配器。
若是你还什么都没有，可是想分开实现，那么桥接是一个选择。

桥接是先有桥，才有两端的东西
适配是先有两边的东西，才有适配器

桥接是在桥好了以后，两边的东西还能够变化。

 

桥梁模式

抽象与实现

抽象不该该依赖于实现细节，实现细节应该依赖于抽象。

问题在于若是抽象B因为固有的缘由，自己并不稳定，也有可能变化，怎么办？

 

举例来讲

假如咱们须要开发一个同时支持PC和手机的坦克游戏，游戏在PC和手机上功能都同样，都有一样的类型，面临一样的功能需求变化，好比坦克可能有不少种不一样的型号：T50，T75，T90……

对于其中的坦克设计，咱们可能很容易设计出来一个Tank的抽象基类，而后各类不一样型号的Tank继承自该类;

 

另外的变化缘由

可是PC和手机上的图形绘制、声效、操做等实现彻底不一样……所以对于各类型号的坦克，都要提供各类不一样平台上的坦克实现：

这样的设计会带来不少问题：有不少重复代码，类的结构过于复杂，难以维护，最致命的是引入任何新平台，好比在TV上的Tank游戏，都会让整个类层级结构复杂化。

 

动机（Motivation）

思考上述问题的症结：事实上因为Tank类型的固有逻辑，使得Tank类型具备了两个变化的维度——一个变化的维度为“平台的变化”，一个变化的维度为“型号的变化”。

如何应对这种“多维度的变化”？如何利用面向对象技术来使得Tank类型能够轻松地沿着“平台”和“型号”两个方向变化，而不引入额外的复杂度？

 

意图（Intent）

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

——《设计模式》GoF

桥模式不能只是认为是抽象和实现的分离，它其实并不只限于此。以下面的例子，两个都是抽象的部分。更确切的理解，应该是将一个事物中多个维度的变化分离。

 对于这种在多个维度上都会有变化或扩充需求的项目来讲，能够考虑引入桥接模式。或许你会说，不论是什么场景，无论什么模式，均可以是抽象场景的一个子类，可是，若是这样的话，4个场景和3种模式就会产生12个子类，而10个场景5种模式就会有50个子类。一味进行继承并非什么好方法，桥接模式的思想是把继承转化为组合，把乘法(10*5=50)转化为加法(10+5=15)。 

例说Bridge应用

版本一 

先写各类不一样的坦克型号类T50、T75等继承自Tank，而后再让各类平台的坦克继承自对应型号的类，如PCT50，PCT75继承自T50等。这样设计可能会有不少重复的代码，例PCT50和PCT75。

 

版本二

由于平台和坦克型号都是变化，因此咱们把平台的变化做为属性放到基抽象类中。

平台实现类

下面是整个代码的骨架

Tank的型号，和Tank的平台都继承自各自的抽象类，所以它们的变化都不会影响到对方。而它们之间的关联，咱们使用组合的方式，把平台类放到Tank类中做为属性。这再次体现了组合优先于继承的思想。多继承的方法就是版本一的代码，这种方式子类和父类的关系太紧，形成紧耦合。

这就是桥模式，把变化引出了基类Tank，使得Tank仅守与型号的变化。

 

应用程序

在环境交互中使用的都是抽象类，而且把平台实现隐藏，在应用程序中new平台的方式也能够根据状况用Singleton模式或者Abstract Factory模式等实现。

 

结构（Structure）

其中imp的地方就是一个组合。Abstraction就是咱们以前例子中的Tank，它的子类RefinedAbstraction就是T50等型号。Implementor是TankPlatformImplementation类，ConcreteImplementorA和ConcreteImplementorB分别是PCTankImplementation和MobileTankImplementation。

整个设计模式的关键就是组合的使用。

 

Bridge模式的几个要点

Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象（Tank的型号）和实现（不一样的平台）能够沿着格子的维度来变化。

所谓抽象和实现沿着各自维度的变化，即“子类化”它们（好比不一样的Tank型号子类，和不一样的平台子类），获得各个子类以后，即可以任意组合它们，从而得到不一样平台上的不一样型号。

Bridge模式有时候相似于多继承方案，可是多继承方案每每违背单一职责原则（即一个类只有一个变化的缘由），复用性比较差。Bridge模式是比多继承方案更好的解决方法。

下面是针对上面的例子，多继承接口的一种写法： 

这样PCT50既须要写T50的实现，又要写Platform的实现，它把型号和平台的变化都引入了PCT50。这样就把两个本不应扭在一块儿的事务扭在了一块儿，这样的设计更加糟糕，并且也违背了类的单一职责原则。

Bridge模式的应用通常在“两个很是强的变化维度”，有时候即便有两个变化的维度，可是某个方向的变化维度并不剧烈——换言之两个变化不会致使纵横交错的结果，并不必定要使用Bridge模式。

 

桥模式并不一样于适配器模式，适配器模式实际上是一个过后诸葛亮，当发现之前的东西不适用了才去作一个弥补的措施。桥模式相对来讲所作的改变比适配器模式早，它能够适用于有两个甚至两个以上维度的变化。