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

网桥和适配器模式有什么区别？ 我可以在哪里使用每种模式？

“适配器在devise完成之后就可以工作; Bridge使它们在它们之前工作[GoF，p219]”

实际上，当你有现有的代码，无论是第三方，还是内部的，但不在你的控制之下，或者不能改变以适应你所需要的接口，Adapter模式都是有用的。 例如，我们有一个SuperWeaponsArray可以控制一系列的世界末日装置。 

public class SuperWeaponsArray { /*...*/ public void destroyWorld() { for (Weapon w : armedWeapons) { w.fire(); } } }

大。 除非我们意识到我们的武器库中有一个核装置，远远超过了转换到武器界面的时间。 但我们真的很喜欢它在这里工作…所以我们做什么…楔入！

NukeWeaponsAdaptor – 基于我们的Nuke类，但是出口Weapon接口。 甜，现在我们可以肯定地摧毁这个世界。 这似乎是一个杂凑，但它使事情工作。

Bridge模式是你在前面实现的东西 – 如果你知道你有两个正交的层次结构，它提供了一种方法来解耦接口和实现，这样你就不会有疯狂的类。 假设你有：

MemoryMappedFile和DirectReadFiletypes的文件对象。 假设您希望能够读取各种来源的文件（也许Linux和Windows的实现等）。 大桥可以帮助您避免发生以下情况：

MemoryMappedWindowsFile MemoryMappedLinuxFile DirectReadWindowsFile DirectReadLinuxFile

http://en.wikipedia.org/wiki/Adapter_pattern

适配器模式更多的是让您的现有代码与更新的系统或界面一起工作。

如果您有一套您希望提供给另一个应用程序的现有可扩展性界面的公司标准Web服务API，则可以考虑编写一组适配器来执行此操作。 请注意，有一个灰色区域，这更多的是关于如何从技术上定义模式，因为其他模式，如外观相似。

http://en.wikipedia.org/wiki/Bridge_pattern

Bridge模式将允许您可能有一个algorithm或系统的替代实现。

尽pipe不是典型的Bridge模式示例，但是想象一下，如果您有一些数据存储的实现：一个在空间上是有效的，另一个在原始性能方面是高效的……并且您有一个在您的应用程序或框架中提供的商业案例。

就您的问题而言，“哪里可以使用哪种模式”，答案就是，无论您的项目有何意义， 也许考虑提供一个澄清编辑指导讨论你认为你需要使用哪一个或哪一个。

这篇文章已经有相当长的一段时间了。 然而，了解一个门面有点类似于一个适配器是非常重要的，但它不是一回事。 适配器将现有的类“适应”到通常不兼容的客户端类。 假设您的应用程序正在使用一个旧的工作stream系统作为客户端。 您的公司可能会用新的“不兼容的”（就接口而言）replace工作stream系统。 在大多数情况下，您可以使用适配器模式并编写实际调用新工作stream引擎接口的代码。 桥梁通常以不同的方式使用。 如果实际上有一个系统需要使用不同的文件系统（即本地磁盘，NFS等），则可以使用桥接模式并创build一个抽象层来处理所有文件系统。 这基本上是一个桥梁模式的简单用例。 Facade和适配器共享一些属性，但通常用Facade来简化现有的接口/类 。 在EJB的早期，没有EJB的本地调用。 开发人员总是得到这个存根，缩小范围，称之为“伪远程”。 这通常会导致性能问题（尤其是在通过电线实际调用时）。 有经验的开发人员可以使用门面模式为客户端提供非常粗糙的界面。 然后，这个外观会反过来对不同的更细粒度的方法进行多次调用。 总而言之，这大大减less了所需的方法调用次数，提高了性能。

适配器：

  1. 这是一个结构模式
  2. 使用两个不兼容的接口是很有用的

UML图：来自dofactory文章：

在这里输入图像说明

目标 ：定义客户端使用的特定于域的界面。

适配器 ：将接口适配器调整到目标接口。

适配器 ：定义需要适应的现有接口。

客户端 ：与符合目标界面的对象协作。

例：

正方形和矩形是两种不同的形状，每个区域的获取面积（）需要不同的方法。 但是Square仍然可以在Rectangle接口上转换一些属性。 

 public class AdapterDemo{ public static void main(String args[]){ SquareArea s = new SquareArea(4); System.out.println("Square area :"+s.getArea()); } } class RectangleArea { public int getArea(int length, int width){ return length * width; } } class SquareArea extends RectangleArea { int length; public SquareArea(int length){ this.length = length; } public int getArea(){ return getArea(length,length); } }

桥：

  1. 这是结构模式
  2. 它将抽象从其实现中分离出来，两者可以独立地变化
  3. 这是可能的，因为组成已被用来代替inheritance

编辑:(根据@quasoftbuild议）

这种模式中有四个组件。

  1. 抽象 ：它定义了一个接口

  2. RefinedAbstraction ：它实现抽象：

  3. 实现者 ：它定义了一个实现的接口

  4. 具体实现：实现Implementor接口。

代码片段： 

 Gear gear = new ManualGear(); Vehicle vehicle = new Car(gear); vehicle.addGear(); gear = new AutoGear(); vehicle = new Car(gear); vehicle.addGear();

相关文章：

你什么时候使用桥梁模式？ 与适配器模式有什么不同？

主要区别：源自文章

  1. 适配器在devise完成后就可以使用。 桥在他们之前使他们工作。
  2. 预先devise网桥，使抽象和实现独立变化。 适配器进行改造，使无关的class级一起工作。

假设你有一个具有（通用/抽象）绘图function的抽象Shape类和一个实现Shape的Circle。 桥接模式简单地说是一种双向抽象方法，用于分离实现（以Circleforms绘制）和generics/抽象function（在Shape类中绘制）。

这是什么意思？ 乍一看，这听起来像是你已经做的事情（通过依赖倒置）。 所以不用担心有更less的ridig或更多的模块化代码库。 但是它背后的哲学有点深刻。

根据我的理解，当我需要添加与当前系统（如RedCircle或GreenCircle）密切相关的新类时，可能会出现使用模式的需求，并且它们仅通过单一function（如颜色）而不同。 而且我将需要Bridge模式，特别是如果现有的系统类（Circle或Shape）要频繁更改，并且不希望新增的类受到这些更改的影响。 所以这就是为什么通用绘图function被抽象到一个新的界面，以便您可以独立于Shape或Circle来改变绘图行为。

桥是改进的适配器。 桥包括适配器，并增加了额外的灵活性。 下面是Ravindra的答案在graphics之间的映射： 

  Adapter | Bridge -----------|--------------- Target | Abstraction -----------|--------------- | RefinedAbstraction | | This element is Bridge specific. If there is a group of | implementations that share the same logic, the logic can be placed here. | For example, all cars split into two large groups: manual and auto. | So, there will be two RefinedAbstraction classes. -----------|--------------- Adapter | Implementor -----------|--------------- Adaptee | ConcreteImplementor
    Interesting Posts

    你什么时候使用桥梁模式？ 与适配器模式有什么不同？

    代理，装饰器，适配器和桥接模式如何不同？