“适配器在设计完成后就可以使用; Bridge使它们在使用之前就能正常工作[GoF，p219]”

实际上，适配器模式在您拥有现有代码，无论是第三方还是内部代码，但不在您的控制范围内，或以其他方式无法更改以完全符合您所需的界面时非常有用。例如，我们有一个SuperWeaponsArray可以控制一系列的末日装置。

public class SuperWeaponsArray {
  /*...*/

  public void destroyWorld() {
    for (Weapon w : armedWeapons) {
      w.fire();
    }
  }
}

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

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

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

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

MemoryMappedWindowsFile MemoryMappedLinuxFile DirectReadWindowsFile DirectReadLinuxFile

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

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

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

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

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

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

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