什么时候使用桥接模式？它与适配器模式有何不同？

Question

有没有人在现实世界的应用程序中使用过Bridge Pattern？如果是这样，你是如何使用它的？是我，还是只是适配器模式加上一点依赖注入？它真的值得拥有自己的模式吗？

Answer 1

Federico's 和 John's 答案的组合。

时间：

                   ----Shape---
                  /            \
         Rectangle              Circle
        /         \            /      \
BlueRectangle  RedRectangle BlueCircle RedCircle

重构为：

          ----Shape---                        Color
         /            \                       /   \
Rectangle(Color)   Circle(Color)           Blue   Red

Answer 2

桥接模式是旧建议的应用，“更喜欢组合而不是继承”。 当您必须以相互正交的方式对不同时间进行子类化时，它会变得很方便。假设您必须实现彩色形状的层次结构。你不会用 Rectangle 和 Circle 子类 Shape，然后用 RedRectangle、BlueRectangle 和 GreenRectangle 子类 Rectangle，Circle 也是如此，对吗？您更愿意说每个形状有一个颜色并实现颜色的层次结构，这就是桥接模式。好吧，我不会实现“颜色层次结构”，但你明白了......

Answer 3

时间：

        A
     /     \
    Aa      Ab
   / \     /  \
 Aa1 Aa2  Ab1 Ab2

重构为：

     A         N
  /     \     / \
Aa(N) Ab(N)  1   2

Answer 4

在 UI 环境中定义形状时使用了桥模式的经典示例（请参阅Bridge pattern Wikipedia entry）。 Bridge 模式是Template 和Strategy 模式中的composite。

这是桥模式中适配器模式某些方面的常见观点。但是，引用this article：

乍一看，桥接模式看起来很像适配器模式，因为一个类用于将一种接口转换为另一种接口。但是，适配器模式的目的是使一个或多个类的接口看起来与特定类的接口相同。桥接模式旨在将类的接口与其实现分开，这样您就可以在不更改客户端代码的情况下更改或替换实现。

Answer 5

根据我的经验，Bridge 是一种经常重复出现的模式，因为只要域中有两个正交维度，它就是解决方案。例如。形状和绘制方法、行为和平台、文件格式和序列化程序等等。

还有一个建议：始终从概念的角度考虑设计模式，而不是从实现的角度。从正确的角度来看，Bridge 不能与 Adapter 混淆，因为它们解决了不同的问题，组合优于继承不是因为它本身，而是因为它允许单独处理正交关注点。

Answer 6

Adapter 和 Bridge 肯定是相关的，而且区别很微妙。很可能有些人认为他们正在使用其中一种模式，实际上他们正在使用另一种模式。

我看到的解释是当你试图统一一些已经存在的不兼容类的接口时使用了Adapter。适配器充当一种翻译器，可被视为legacy的实现。

而桥模式用于更有可能是未开发的代码。您正在设计 Bridge 为需要变化的实现提供抽象接口，但您还定义了这些实现类的接口。

设备驱动程序是 Bridge 的一个经常被引用的示例，但如果您为设备供应商定义接口规范，我会说它是一个 Bridge，但如果您使用现有的设备驱动程序并制作一个包装器，它就是一个适配器-class 提供统一的接口。

所以在代码方面，这两种模式非常相似。在业务方面，它们是不同的。

另见http://c2.com/cgi/wiki?BridgePattern

Answer 7

Bridge 和 Adapter 的意图不同，我们分别需要这两种模式。

桥接模式：

1. 这是一种结构模式
2. 抽象和实现在编译时不受约束
3. 抽象和实现 - 两者都可以变化而不会对客户端产生影响
4. 使用组合而不是继承。

在以下情况下使用桥接模式：

1. 您想要实现的运行时绑定，
2. 由于耦合接口和众多实现，您拥有大量的类，
3. 您希望在多个对象之间共享一个实现，
4. 您需要映射正交类层次结构。

@ John Sonmez 的回答清楚地表明了桥接模式在减少类层次结构方面的有效性。

您可以参考以下文档链接，通过代码示例更好地了解桥接模式

适配器模式：

1. 它允许两个不相关的接口通过不同的对象一起工作，可能扮演相同的角色。
2. 它修改了原来的界面。

主要区别：

1. Adapter 让事情在设计之后就可以工作； Bridge 让他们先于工作。
2. Bridge 是预先设计的，让抽象和实现独立变化。 Adapter 进行了改造，使不相关的类可以协同工作。
3. 意图：适配器允许两个不相关的接口一起工作。 Bridge 允许抽象和实现独立变化。

与 UML 图和工作代码相关的 SE 问题：

Difference between Bridge pattern and Adapter pattern

有用的文章：

sourcemaking bridge模式文章

sourcemaking adapter模式文章

journaldev bridge模式文章

编辑：

Bridge Pattern 真实世界示例（根据 meta.stackoverflow.com 的建议，在这篇文章中包含文档站点示例，因为文档即将结束）

桥接模式将抽象与实现分离，因此两者都可以独立变化。它是通过组合而不是继承实现的。

来自维基百科的桥接模式 UML：

您在此模式中有四个组件。

Abstraction: 定义了一个接口

RefinedAbstraction：它实现了抽象：

Implementor：定义了一个实现接口

ConcreteImplementor：实现了Implementor接口。

The crux of Bridge pattern : 两个正交的类层次结构使用组合（并且没有继承）。抽象层次结构和实现层次结构可以独立变化。实现从不指抽象。抽象包含实现接口作为成员（通过组合）。这种组合减少了一层继承层次。

实词用例：

让不同的车辆同时拥有手动和自动两个版本的齿轮系统。

示例代码：

/* Implementor interface*/
interface Gear{
    void handleGear();
}

/* Concrete Implementor - 1 */
class ManualGear implements Gear{
    public void handleGear(){
        System.out.println("Manual gear");
    }
}
/* Concrete Implementor - 2 */
class AutoGear implements Gear{
    public void handleGear(){
        System.out.println("Auto gear");
    }
}
/* Abstraction (abstract class) */
abstract class Vehicle {
    Gear gear;
    public Vehicle(Gear gear){
        this.gear = gear;
    }
    abstract void addGear();
}
/* RefinedAbstraction - 1*/
class Car extends Vehicle{
    public Car(Gear gear){
        super(gear);
        // initialize various other Car components to make the car
    }
    public void addGear(){
        System.out.print("Car handles ");
        gear.handleGear();
    }
}
/* RefinedAbstraction - 2 */
class Truck extends Vehicle{
    public Truck(Gear gear){
        super(gear);
        // initialize various other Truck components to make the car
    }
    public void addGear(){
        System.out.print("Truck handles " );
        gear.handleGear();
    }
}
/* Client program */
public class BridgeDemo {    
    public static void main(String args[]){
        Gear gear = new ManualGear();
        Vehicle vehicle = new Car(gear);
        vehicle.addGear();

        gear = new AutoGear();
        vehicle = new Car(gear);
        vehicle.addGear();

        gear = new ManualGear();
        vehicle = new Truck(gear);
        vehicle.addGear();

        gear = new AutoGear();
        vehicle = new Truck(gear);
        vehicle.addGear();
    }
}

输出：

Car handles Manual gear
Car handles Auto gear
Truck handles Manual gear
Truck handles Auto gear

解释：

1. Vehicle 是一个抽象。
2. Car 和 Truck 是 Vehicle 的两个具体实现。
3. Vehicle 定义了一个抽象方法：addGear()。
4. Gear 是实现接口
5. ManualGear 和 AutoGear 是 Gear 的两个实现
6. Vehicle 包含 implementor 接口而不是实现接口。实现者接口的Compositon 是这种模式的关键：它允许抽象和实现独立变化。
7. Car 和 Truck 为抽象定义实现（重新定义抽象）：addGear()：它包含 Gear - Manual 或 Auto

桥接模式用例：

1. 抽象和实现可以相互独立变化，并且在编译时不受约束
2. 映射正交层次结构 - 一个用于抽象，一个用于实现。

Answer 8

我在工作中使用了桥接模式。我用 C++ 编程，它通常被称为 PIMPL 习惯用法（指向实现的指针）。它看起来像这样：

class A
{
public: 
  void foo()
  {
    pImpl->foo();
  }
private:
  Aimpl *pImpl;
};

class Aimpl
{
public:
  void foo();
  void bar();
};  

在此示例中，class A 包含接口，class Aimpl 包含实现。

这种模式的一个用途是只公开实现类的一些公共成员，而不公开其他成员。示例中只有Aimpl::foo()可以通过A的公共接口调用，Aimpl::bar()不能调用

另一个优点是您可以在单独的头文件中定义Aimpl，A 的用户不需要包含该文件。您所要做的就是在定义A 之前使用Aimpl 的前向声明，并将所有引用pImpl 的成员函数的定义移动到.cpp 文件中。这使您能够保持 Aimpl 标头私有，并减少编译时间。

Answer 9

将形状示例放入代码中：

#include<iostream>
#include<string>
#include<cstdlib>

using namespace std;

class IColor
{
public:
    virtual string Color() = 0;
};

class RedColor: public IColor
{
public:
    string Color()
    {
        return "of Red Color";
    }
};

class BlueColor: public IColor
{
public:
    string Color()
    {
        return "of Blue Color";
    }
};


class IShape
{
public:
virtual string Draw() = 0;
};

class Circle: public IShape
{
        IColor* impl;
    public:
        Circle(IColor *obj):impl(obj){}
        string Draw()
        {
            return "Drawn a Circle "+ impl->Color();
        }
};

class Square: public IShape
{
        IColor* impl;
    public:
        Square(IColor *obj):impl(obj){}
        string Draw()
        {
        return "Drawn a Square "+ impl->Color();;
        }
};

int main()
{
IColor* red = new RedColor();
IColor* blue = new BlueColor();

IShape* sq = new Square(red);
IShape* cr = new Circle(blue);

cout<<"\n"<<sq->Draw();
cout<<"\n"<<cr->Draw();

delete red;
delete blue;
return 1;
}

输出是：

Drawn a Square of Red Color
Drawn a Circle of Blue Color

请注意，可以轻松地将新颜色和形状添加到系统中，而不会因排列而导致子类爆炸。

Answer 10

您在一家保险公司工作，您在该公司开发一个工作流应用程序来管理不同类型的任务：会计、合同、索赔。这就是抽象。在实施方面，您必须能够从不同来源创建任务：电子邮件、传真、电子邮件。

你从这些类开始你的设计：

public class Task {...}
public class AccountingTask : Task {...}
public class ContractTask : Task {...}
public class ClaimTask : Task {...}

现在，由于必须以特定方式处理每个来源，因此您决定专门针对每种任务类型：

public class EmailAccountingTask : AccountingTask {...}
public class FaxAccountingTask : AccountingTask {...}
public class EmessagingAccountingTask : AccountingTask {...}

public class EmailContractTask : ContractTask {...}
public class FaxContractTask : ContractTask {...}
public class EmessagingContractTask : ContractTask {...}

public class EmailClaimTask : ClaimTask {...}
public class FaxClaimTask : ClaimTask {...}
public class EmessagingClaimTask : ClaimTask {...}

您最终获得了 13 个课程。添加任务类型或源类型变得具有挑战性。通过将任务（抽象）与源（这是一个实现问题）解耦，使用桥接模式可以更容易地维护：

// Source
public class Source {
   public string GetSender();
   public string GetMessage();
   public string GetContractReference();
   (...)
}

public class EmailSource : Source {...}
public class FaxSource : Source {...}
public class EmessagingSource : Source {...}

// Task
public class Task {
   public Task(Source source);
   (...)
}
public class AccountingTask : Task {...}
public class ContractTask : Task {...}
public class ClaimTask : Task {...}

现在添加任务类型或来源变得更加容易。

注意：大多数开发人员不会预先创建 13 个类层次结构来处理此问题。但是，在现实生活中，您可能事先不知道源和任务类型的数量；如果您只有一个源和两种任务类型，您可能不会将任务与源分离。然后，随着新源和任务类型的添加，整体复杂性会增加。在某些时候，您将进行重构，并且通常会得到一个类似桥的解决方案。

Answer 11

对我来说，我认为它是一种可以交换接口的机制。在现实世界中，您可能有一个可以使用多个接口的类，Bridge 允许您交换。

Answer 12

如果你得到相同的旧形状和颜色示例的板，我会给你一个新的桥模式示例。

假设您有不同的付款方式，例如信用卡付款和网上银行。还有花旗银行和汇丰银行等不同的支付网关。

然后您只需将支付网关成员添加到支付模式即可。并在运行时将此信息传递给支付模式对象。然后付款。

例如，它将在 CITI 银行支付网关上进行卡支付。

Answer 13

Bridge design pattern we can easily understand helping of service and dao layer.

Dao layer -> create common interface for dao layer ->
public interface Dao<T>{
void save(T t);
}
public class AccountDao<Account> implement Dao<Account>{
public void save(Account){
}
}
public LoginDao<Login> implement Dao<Login>{
public void save(Login){
}
}
Service Layer ->
1) interface
public interface BasicService<T>{
    void save(T t);
}
concrete  implementation of service -
Account service -
public class AccountService<Account> implement BasicService<Account>{
 private Dao<Account> accountDao;
 public AccountService(AccountDao dao){
   this.accountDao=dao;
   }
public void save(Account){
   accountDao.save(Account);
 }
}
login service- 
public class LoginService<Login> implement BasicService<Login>{
 private Dao<Login> loginDao;
 public AccountService(LoginDao dao){
   this.loginDao=dao;
   }
public void save(Login){
   loginDao.save(login);
 }
}

public class BridgePattenDemo{
public static void main(String[] str){
BasicService<Account> aService=new AccountService(new AccountDao<Account>());
Account ac=new Account();
aService.save(ac);
}
}
}