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

Question

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

score 268 · Accepted Answer

Federico和John 的答案是混合的。

什么时候：

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

重构为：

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

score 239 · Accepted Answer

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

score 224 · Accepted Answer

什么时候：

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

重构为：

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

score 80 · Accepted Answer

在 UI 环境中定义形状时使用了 Bridge 模式的一个经典示例（请参阅Bridge 模式 Wikipedia 条目）。桥接模式是模板和策略模式的组合。

它是桥接模式中适配器模式某些方面的常见观点。但是，引用这篇文章：

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

score 31 · Accepted Answer

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

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

score 30 · Accepted Answer

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

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

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

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

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

另请参阅http://c2.com/cgi/wiki?BridgePattern

score 24 · Accepted Answer

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

桥梁模式：

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

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

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

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

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

适配器模式：

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

主要区别：

适配器在设计完成后就可以工作；Bridge让它们先于它们工作。
Bridge是预先设计的，让抽象和实现独立变化。改装适配器以使不相关的类一起工作。
意图：适配器允许两个不相关的接口一起工作。Bridge允许抽象和实现独立变化。

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

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

有用的文章：

sourcemaking桥模式文章

sourcemaking 适配器模式文章

journaldev 桥模式文章

编辑：

桥接模式真实世界示例（根据 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

桥接模式的用例：

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

score 9 · Accepted Answer

我在工作中使用了桥接模式。我用 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. 您所要做的就是使用Aimplbefore Ais defined 的前向声明，并将所有引用的成员函数的定义移动pImpl到 .cpp 文件中。这使您能够保持Aimpl标头私有，并减少编译时间。

score 7 · Accepted Answer

将形状示例放入代码中：

#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

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

score 3 · Accepted Answer

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

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

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

如果您获得相同旧形状和颜色示例的板，我将为您提供一个新的桥模式示例。

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

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

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

score -6 · Accepted Answer

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

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

13 回答 13

Related

Reference