桥接模式与适配器模式的区别

假设您有一个具有(通用/抽象)绘图功能的抽象形状类和一个实现形状的 Circle。桥模式只是一种双向抽象方法，用于解耦实现(在 Circle 中绘制)和通用/抽象功能(在 Shape 类中绘制)。

这到底意味着什么？乍一看，它听起来像是您已经创建的东西(通过依赖性反转)。因此，不用担心拥有一个不那么死板或更模块化的代码库。但这背后有更深层次的哲学。

根据我的理解，当我需要添加与当前系统密切相关的新类(如 RedCircle 或 GreenCircle)并且它们只有一个功能(如颜色)不同时，可能会出现使用模式的需要。我需要桥模式，特别是如果现有的系统类(圈或形状)是经常变化的，你不希望新添加的类受到这些变化的影响。因此，这就是为什么通用绘图功能被抽象到一个新的界面，以便您可以改变绘图行为独立于形状或圆。

桥是改进的适配器。桥包括适配器，并增加了额外的灵活性。 下面是拉文德拉答案中的元素如何在模式之间映射:

      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

在最上面的回答中,@James 引用了 GoF 的一句话，第219页。我认为在这里重复完整的解释是值得的。

适配器对决桥梁

Adapter 和 Bridge 模式具有一些公共属性。两者都通过向另一个对象提供一定程度的间接性来提高灵活性。两者都有 将请求从自己的接口以外的接口转发到此对象。

这些模式之间的关键区别在于它们的意图 解决两个现有接口之间的不兼容问题 这些接口是实现的，也没有考虑它们如何独立发展。这是一种让两个独立设计的类一起工作的方法 而不是重新实现其中一个。另一方面，桥接抽象及其(潜在的大量)实现。它提供了一个稳定的接口 即使它允许你改变实现它的类 随着系统的发展，会有新的实现。

由于这些差异，适配器和桥经常用在不同的地方 在软件生命周期中，适配器通常是必要的，当你发现 两个不兼容的类应该一起工作，通常是为了避免复制代码 相比之下，桥接器的用户事先就知道 抽象必须有几个实现，并且两者都可以独立发展。 适配器模式使事物工作 之后他们被设计; 桥梁使他们 工作 之前他们。这并不意味着适配器在某种程度上不如桥梁; 每个 模式只是解决了一个不同的问题。

根据另一个堆栈溢出问题的答案 给你，我觉得这个问题的答案更简洁明了:

• Adapter 在您有一个抽象接口时使用，并且您希望使用 将该接口映射到另一个具有类似功能的对象 角色，但界面不同。

• Bridge 与 Adapter 非常相似，但我们称之为 Bridge 定义抽象接口和底层实现。 也就是说，你不是在适应某些遗产或第三方代码，你是 所有代码的设计者，但你需要能够交换出来 不同的实现。

有很多答案可以区分适配器和桥接器。 但是当 ppl 正在寻找代码示例时，我将给出一个关于适配器设计模式的示例，它被精心制作成一个时间轴故事:

    //---------------------------------------External Vendor/Provider--------------------------------
   

//Adaptee | RussianTankInterface is adaptee | adaptee lives in is own lala land and do not care about any other class or interface
RussianTankInterface smerch9K58 = new RussianTank("The Russian Artillery bought by India in October 2015");
smerch9K58.aboutMyself();
smerch9K58.stuff();
smerch9K58.rotate();
smerch9K58.launch();
        

   

//---------------------------------2016 : India manufactures Bharat52 ------------------------------
    

//Client_1 :: IndianTank
EnemyAttacker bharat52Attacker = new IndianTank("Tank built in India delivered to Army in Jul 2016");
   

// behaves normally -------------------------(1)
bharat52Attacker.aboutMe();
bharat52Attacker.load();
bharat52Attacker.revolve();
bharat52Attacker.fireArtillery();
                

//---------------------------------2019 : India mnufactures Pinaka, and thought about fusion with Russian technology - so adaption required ------------------------------
                  

//Client_2 :: IndianTank
EnemyAttacker pinakaAttacker = new IndianTank("Tank built in India in 1998 got upgraded_v1 in 9 Sep 2019");
            

            

            

#####----Bilateral-Coalition happens----##
#####       India  : I want a fusion artillery technology with
#####                       1) Indian materials and brain-power but
#####                       2) Russian machine-parts-movement technology
#####       Russia : Give me your Interface - at max we can help by providing an Adapter
    

//---------------------------------------External Vendor/Provider-----------------------------------
    

//Adapter :: RussianTechnologyAdapter | Russia gets EnemyAttacker interface only from India & creates RussianTechnologyAdapter
RussianTechnologyAdapter russianTechnologyAdapter = new RussianTechnologyAdapter(smerch9K58);
           

           

//Target | EnemyAttacker was initially ClientInterface but later becomes the Target as story evolves | <- client owns this Interface
EnemyAttacker dhanushAttacker = russianTechnologyAdapter;
            

#####----Russia keeps her Word----##
#####       Russia to India : Here you go! Take Dhanush, a wrapper over our encapsulated adapter, and plug-in anything conforming to your EnemyAttacker.
#####       India : Thanks a lot!


//--------------------------------- 2020 : India returns back happily with dhanushAttacker---------------------------------------
            

//Client_2 - adapted behavior -------------------------(2)
dhanushAttacker.setNavigationCapability(pinakaAttacker.getCuttingEdgeNavigableTargets());
dhanushAttacker.aboutMe(); //calls RussianInstance -> aboutMyself()
dhanushAttacker.load();    //calls RussianInstance -> stuff()
dhanushAttacker.revolve(); //calls RussianInstance -> rotate()
dhanushAttacker.fireArtillery();  //calls RussianInstance -> launch()
                       

          

仔细注意:

• (1) & (2)中相同的 API 的行为不同
• 印度可以把大脑植入俄罗斯的线框，例如 dhanushAttacker.setNavigationCapability(pinakaAttacker.get(..))

值得注意的地方

客户方拥有:

-  Invoker /Use(uses Adapter later point)/Client
-  ClientInterface (a.k.a Target )

稍后分享:

- ClientInterface  ( becomes Target after sharing)

接收方拥有:

- Adapter (later shared directly or as a wrapper )
- Adaptee


     

希望有人也为 Bridge 提供一个内联:)

Bridge 与 Adapter 非常相似，但是当你定义抽象接口和底层实现时，我们称之为 Bridge，意思是不适应外部代码，你是所有代码的设计者，但是你需要能够交换不同的实现。

我觉得很简单。

适配器旨在允许第三方应用程序使用您的应用程序。 相反，这样您的应用程序可以与第三方应用程序一起工作。

使用桥接模式，假设它连接两个或多个应用程序，而不实现适配器。

实际上，桥是两个应用程序通过其进行交互的接口。作为桥接的一个例子，这些是 PHP 中的 PSR 接口。

例如:

其他应用

<?php


interface IRequestDataOtherApp {};
 

interface IResponseDataOtherApp {};
 

class ResponseDataOtherApp implements IResponseDataOtherApp   {


};
 

class OtherApp {
public static function request(IRequestDataOtherApp $requestData):IResponseOtherApp
{
// code
return new ResponseDataOtherApp ();
}
}

MyApp

<?php


interface IResponseDataMyApp {};


interface IReqestDataMyApp {};


class ReqestDataMyApp implements IReqestDataMyApp {};


class Adapter {
   

public static function convertResponseData(IResponseDataOtherApp $response):IResponseDataMyApp
{
      

}
public static function convertRequestData(IReqestDataMyApp $request):IRequestOtherApp
{
      

}
};
$unformattedResponse=OtherApp::request(Adapter::convertRequestData(new ReqestDataMyApp ()));
$myResponse=ResponseAdapter::convertResponseData($unformattedResponse);
//...

在前面的示例中，我们为每个请求和每个响应实现了2个适配器。 如果我们重写示例并尝试实现桥接。

<?php
interface IBridgeResponse {};

其他应用

<?php
interface IRequestDataOtherApp {};
interface IResponseDataOtherApp {};
 

class ResponseDataOtherApp  implements IBridgeResponse, IResponseDataOtherApp   {


};
 

class OtherApp {
public static function request(IRequestDataOtherApp $requestData):IResponseOtherApp
{
// code
return new ResponseDataOtherApp  ();
}
}

MyApp

<?php


interface IResponseDataMyApp {};


interface IReqestDataMyApp {};


class ReqestDataMyApp implements IReqestDataMyApp {};


class Adapter {


public static function convertResponseData(IResponseDataOtherApp $response):IResponseDataMyApp
{
      

}


public static function convertRequestData(IReqestDataMyApp $request):IRequestOtherApp
{
      

}
};


$response=OtherApp::request(Adapter::convertRequestData(new ReqestDataMyApp ()));


if($response instanceof IBridgeResponse){
/**
The component has implemented IBridgeResponse interface,
thanks to which our application can interact with it.
This is the bridge.


Our application does not have to create an additional adapter
(if our application can work with IBridgeResponse).
*/
}
//...

在六边形体系结构中，如果您从一开始就编写应用程序并准备接受正在使用的另一个应用程序的规则，那么端口(接口、合同)可以充当“桥梁”。 否则，您将不得不编写“适配器”。