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

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

共同点

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

不同点

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

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

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

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

       例如游戏手柄，就象个桥，它把你的任何操作转化成指令。
     （虽然，你可以任何操作组合，但是你的操作脱不开山下左右，a,b，选择 ，确定）
      JRE本身就是一个就是一个很好的桥，先写好在linux上执行的Jre，再写好可以在windows下执行的JRE，
      这样无论什么样的Java程序，只要配和相应的Jre就能在Linux或者Windows上运行.
      两个Jre并没有限定你写什么样的程序，但要求你必须用Java来写。

--------------------------------------------------------

在这篇文章中，我写了Bridge和adapter模式的区别.但是 maninred说
Bridge和adapter是没有关系的，而和Facade比较象，但在我的经验中更多的时候
是会混淆Bridge和adapter而不是Facade，这里详细的列出三个模式的比较 .

一. 定义:

1.  Facade模式是为一个复杂系统提供一个简单的接口。
比如你要去博物馆参观，很多东西，你一个个到处去问每个东西的管理员很麻烦，所以你找一个导游，让他给你一个个介绍，你只要找到导游就好了。导游就是门面。
2. 适配器模式，引用一下GOF95中的话:
适配器模式是把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法工作的两个类能够工作到一起。
举个例子，例如变压器
3. Bridge模式:
GOF95中的桥梁模式的描述：桥梁模式的用意是"将抽象化与实现化脱耦，使的二者可以独立变化。
例如AWT的实现

二. 目的

1. Facade 模式使用在给一个复杂的系统提供统一的门面(接口),目的是简化客户端的操作,但并没有改变接口.
2. Adapter 模式使用在两个部分有不同的接口的情况,目的是改变接口,使两个部分协同工作
3. 桥接模式 是为了分离抽象和实现

二. 使用场合

1. Facade

   出现较多是这样的情况,你有一个复杂的系统,对应了各种情况,
客户看了说功能不错,但是使用太麻烦.你说没问题,我给你提供一个统一的门面.
所以Facade使用的场合多是对系统的"优化".
2. Adapter

   出现是这样的情况,你有一个类提供接口A,但是你的客户需要一个实现接口B的类,
这个时候你可以写一个Adapter让把A接口变成B接口,所以Adapter使用的场合是
指鹿为马.就是你受夹板气的时候,一边告诉你我只能提供给你A(鹿),一边告诉你说
我只要B(马),他长了四条腿,你没办法了,把鹿牵过去说,这是马,你看他有四条腿.
(当然实现指鹿为马也有两种方法,一个方法是你只露出鹿的四条腿,说你看这是马,这种方式就是
封装方式的Adapter实现,另一种方式是你把鹿牵过去,但是首先介绍给他说这是马,因为他长了四条腿
这种是继承的方式.)
3. Bridge

    在一般的开发中出现的情况并不多,AWT是一个,SWT也算部分是,
如果你的客户要求你开发一个系统,这个系统在Windows下运行界面的样子是Windows的样子.
在Linux下运行是Linux下的样子.在Macintosh下运行要是Mac Os的样子.
怎么办? 定义一系列的控件Button,Text,radio,checkBox等等.供上层开发者
使用,他们使用这些控件的方法,利用这些控件构造一个系统的GUI,然后你为这些控件
写好Linux的实现,让它在Linux上调用Linux本地的对应控件,
在Windows上调用Windows本地的对应控件,在Macintosh上调用Macintosh本地的对应控件
ok,你的任务完成了.

三. 需求程度

1. Facade的需求程度是  "中等"  ,因为你不提供Facade程序照样能工作,只是不够好.
2. Adapter的需求程度是  "必须"  ,因为你不这么做就不能工作,除非你自己从头实现一个.
3. Bridge的需求程度是  "一般"  ,适合精益求精的人,因为你可以写三个程序给客户.

四. 出现时期

1. Facade出现在项目中期,再优化
2. Adapter出现在项目后期,大部分都有了,差的仅仅是接口不同
3. Bridge出现在项目前期,你想让你的系统更灵活,更cool

五. 在写文章的时候想到的

1. Facade很多时候是1:m的关系
2. Adapter很多是候是1:1的关系
3. Bridge很多时候是m:n的关系
呵呵.

六. 最后

另外:回应一下maninred
1. 我并没有把模式看的很独立。

    其实很多模式是配合使用的,而且在一定情况下可以
用一个替换另一个.同一个需求,有可能当你思考的角度不同时,使用的模式就不同了.
2. 设计模式并不是"用OO的封装来封装所有的东西"。

    模式其实可以应用于所有的设计上和OO没有直接的关系,只是因为计算机的设计模式大部分是GOF收集总结的,他们讲解设计模式是用的C++,而在Java中得到了大量应用,所以我们谈到设计模式的时候多提到OO.其实模式更早应用于建筑学,Alexander的《建筑的永恒之道》讲的就是设计模式。所以说设计模式应该是设计过程中积累下来的一些成型的东西。更深入一点，《Java与模式》的作者认为模式起源于中国的道教思想，讲的是哲学。呵呵。
3. 对于模式的使用，个人感觉，模式很大程度上是为了对应这类需求的所有情况。

    也就是最复杂情况，最灵活情况，当我们实际的开发中并没有遇到这么多这样的情况。
所以在需要的时候使用，根据需求简化使用，而不是照搬。
4. 虽然模式是相关的，但是只有知道了每个模式的区别点，才能更好的根据需求选择使用哪个模式。

转载自：http://qinjs.blog.163.com/blog/static/23029492008123627012/