问网桥模式和适配器模式的区别

EN

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

Adapter模式更多的是让您的现有代码与较新的系统或界面协同工作。

如果您有一组公司标准的web服务API，您希望为另一个应用程序的现有可扩展性接口提供这些API，则可以考虑编写一组适配器来实现此目的。请注意，这里有一个灰色区域，这更多的是关于如何在技术上定义模式，因为像facade这样的其他模式是相似的。

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

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

虽然不是一个典型的桥接模式示例，但想象一下，如果您有几个数据存储的实现:一个在空间上高效，另一个在原始性能上高效……并且您有在您的应用程序或框架中提供这两者的业务案例。

对于你的问题，“我可以在哪里使用哪种模式”，答案是，只要对你的项目有意义的地方！也许可以考虑提供一个澄清编辑，以指导讨论您认为需要使用其中一个或另一个。

网桥是改进的适配器。网桥包括适配器，并为其增加了额外的灵活性。以下是Ravindra答案中的元素如何在模式之间映射：

      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

假设您有一个具有(通用/抽象的)绘制功能的抽象Shape类和一个实现该Shape的Circle。Bridge pattern是一种双向抽象方法，用于分离实现(在Circle中绘制)和通用/抽象功能(在Shape类中绘制)。

它的真正含义是什么？乍一看，这听起来像是你已经在做的事情(通过依赖倒置)。因此，不用担心有一个更少模式化或更模块化的代码库。但它背后有更深层次的哲学。

根据我的理解，当我需要添加与当前系统(如RedCircle或GreenCircle )密切相关的新类，并且它们只有一个功能(如颜色)不同时，可能会出现对使用模式的需求。我需要Bridge pattern，特别是如果要频繁更改现有的系统类( Circle或Shape )，并且您不希望新添加的类受到这些更改的影响。这就是为什么通用的绘图功能被抽象到一个新的接口中，这样你就可以独立于Shape或Circle改变绘图行为。