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

Question

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

什么时候：

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

重构为：

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

Answer 5

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

Answer 6

什么时候：

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

重构为：

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

Answer 7

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

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

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

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

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

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

Answer 8

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

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

Answer 9

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

桥梁图案：

这是一种结构模式
抽象和实现不受编译时的约束
抽象和实施 - 两者都可以在客户端没有影响的情况下变化
使用组合而不是继承。

在以下情况下使用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建议，在此文章中包含文档站点示例，因为文档将进行sun-set）

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

来自维基百科的桥模式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

Bridge模式的用例：

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

Answer 10

我在工作中使用了桥模式。我在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 11

在代码中放置形状示例：

#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

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

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

问题描述投票：142回答：11

11个回答

最新问题

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

问题描述 投票：142回答：11

11个回答

最新问题

问题描述投票：142回答：11