Question

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

Answer 1

当：

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

重构为：

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

Answer 2

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

Answer 3

当：

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

重构为：

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

Answer 4

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

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

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

Answer 5

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

我看到的解释是，当您尝试统一已存在的某些不兼容类的接口时，会使用适配器。适配器作为一种转换器，可以被视为 legacy 。

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

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

因此代码方面，这两种模式非常相似。在商业方面，他们是不同的。

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

Answer 6

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

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

Answer 7

Bridge 和适配器的目的不同，我们需要分别使用这两种模式。

桥接模式：

这是一种结构模式
抽象和实现未在编译时绑定
抽象和实施 - 两者都可以在不影响客户的情况下发生变化
使用组合而不是继承。

在以下情况下使用Bridge模式：

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

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

您可以参考以下文档链接，通过代码示例

适配器模式 ：

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

主要差异：

适配器使设计完成后可以正常工作; Bridge 让它们在它们之前工作。
Bridge 是预先设计的，让抽象和实现独立变化。 适配器经过改造，可以使不相关的类一起工作。
意图：适配器允许两个不相关的接口协同工作。 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

说明：

Vehicle是一种抽象。

Car和Truck是Vehicle。
的两个具体实现
Vehicle定义了一种抽象方法：addGear()。

Gear是实现者接口

ManualGear和AutoGear是Gear
的两种实现方式
Vehicle包含implementor接口，而不是实现接口。实现者接口的Compositon是这种模式的关键：它允许抽象和实现独立变化。

Car和Truck定义抽象的实现（重新定义的抽象）：addGear()：它包含Gear - Manual或Auto < / LI>
Bridge模式的用例：

抽象和实施可以相互独立更改，但不会在编译时绑定

映射正交层次结构 - 一个用于抽象，另一个用于实现。

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。您所要做的就是在定义Aimpl之前使用A的前向声明，并将引用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

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

Answer 11

您在一家保险公司工作，在那儿您开发了一个工作流应用程序，该应用程序可以管理各种任务：会计，合同，索赔。这是抽象。在实现方面，您必须能够从不同的来源创建任务：电子邮件，传真，电子消息。

您将从以下类开始设计：

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类层次结构来处理此问题。但是，在现实生活中，您可能不预先知道源和任务类型的数量。如果您只有一个来源和两种任务类型，则可能不会将Task与Source分离。然后，随着添加新的来源和任务类型，总体复杂性也随之增加。在某个时候，您将进行重构，并且通常会得到类似桥梁的解决方案。

Answer 12

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);
}
}
}

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

12 个答案: