blocks|key|1238454|text|http://en.wikipedia.org/wiki/Adapter_pattern|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1238455|Adapter模式更多的是让您的现有代码与较新的系统或界面协同工作。|1238456|如果您有一组公司标准的web服务API，您希望为另一个应用程序的现有可扩展性接口提供这些API，则可以考虑编写一组适配器来实现此目的。请注意，这里有一个灰色区域，这更多的是关于如何在技术上定义模式，因为像facade这样的其他模式是相似的。|1238457|http://en.wikipedia.org/wiki/Bridge_pattern|1238458|Bridge模式将允许您可能拥有算法或系统的替代实现。|1238459|虽然不是一个典型的桥接模式示例，但想象一下，如果您有几个数据存储的实现:一个在空间上高效，另一个在原始性能上高效……并且您有在您的应用程序或框架中提供这两者的业务案例。|1238460|对于你的问题，“我可以在哪里使用哪种模式”，答案是，只要对你的项目有意义的地方！也许可以考虑提供一个澄清编辑，以指导讨论您认为需要使用其中一个或另一个。|1238461|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|18|0|0|0|0|0|17|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|18|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|19|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|4]]|W|$5|S|T|U|C|$V|I]]]]

<a href="http://en.wikipedia.org/wiki/Adapter_pattern" rel="noreferrer">http://en.wikipedia.org/wiki/Adapter_pattern</a>

The Adapter pattern is more about getting your existing code to work with a newer system or interface.

If you have a set of company-standard web service APIs that you'd like to offer to another application's existing extensibility interface, you might consider writing a set of adapters to do this. Note that there's a grey area and this is more about how you technically define the pattern, since other patterns like the facade are similar.

<a href="http://en.wikipedia.org/wiki/Bridge_pattern" rel="noreferrer">http://en.wikipedia.org/wiki/Bridge_pattern</a>

The Bridge pattern is going to allow you to possibly have alternative implementations of an algorithm or system.

Though not a classic Bridge pattern example, imagine if you had a few implementations of a data store: one is efficient in space, the other is efficient in raw performance... and you have a business case for offering both in your app or framework.

In terms of your question, "where I can use which pattern," the answer is, wherever it makes sense for your project! Perhaps consider offering a clarification edit to guide the discussion on where you believe you need to use one or the other.

blocks|key|1453310|text|假设您有一个具有(通用/抽象的)绘制功能的抽象Shape类和一个实现该Shape的Circle。Bridge+pattern是一种双向抽象方法，用于分离实现(在Circle中绘制)和通用/抽象功能(在Shape类中绘制)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1453311|它的真正含义是什么？乍一看，这听起来像是你已经在做的事情(通过依赖倒置)。因此，不用担心有一个更少模式化或更模块化的代码库。但它背后有更深层次的哲学。|1453312|根据我的理解，当我需要添加与当前系统(如RedCircle或GreenCircle+)密切相关的新类，并且它们只有一个功能(如颜色)不同时，可能会出现对使用模式的需求。我需要Bridge+pattern，特别是如果要频繁更改现有的系统类(+Circle或Shape+)，并且您不希望新添加的类受到这些更改的影响。这就是为什么通用的绘图功能被抽象到一个新的接口中，这样你就可以独立于Shape或Circle改变绘图行为。|1453313|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Suppose you've a abstract Shape class with a (generic/abstracted) drawing functionality and a Circle who implements the Shape. Bridge pattern simply is a two-way abstraction approach to decouple the implementation ( drawing in Circle ) and generic/abstracted functionality ( drawing in the Shape class ). 

What does it really mean? At a first glance, it sounds like a something you already making ( by dependency inversion). So no worries about having a less-ridig or more modular code base. But it's a bit deeper philosophy behind it.

From my understanding, the need of usage pattern might emerge when I need to add new classes which are closely related with the current system ( like RedCircle or GreenCircle ) and which they differ by only a single functionality ( like color ). And I'm gonna need Bridge pattern particularly if the existing system classes ( Circle or Shape ) are to be frequently changed and you don't want newly added classes to be affected from those changes. So that's why the generic drawing functionality is abstracted away into a new interface so that you can alter the drawing behaviour independent from Shape or Circle.

blocks|key|1238543|text|网桥是改进的适配器。网桥包括适配器，并为其增加了额外的灵活性。以下是Ravindra答案中的元素如何在模式之间映射：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1238544|++++++Adapter++%7C++++Bridge
++++-----------%7C---------------
++++Target+++++%7C+Abstraction
++++-----------%7C---------------
+++++++++++++++%7C+RefinedAbstraction
+++++++++++++++%7C
+++++++++++++++%7C+++This+element+is+Bridge+specific.+If+there+is+a+group+of+
+++++++++++++++%7C+++implementations+that+share+the+same+logic,+the+logic+can+be+placed+here.
+++++++++++++++%7C+++For+example,+all+cars+split+into+two+large+groups:+manual+and+auto.+
+++++++++++++++%7C+++So,+there+will+be+two+RefinedAbstraction+classes.
++++-----------%7C---------------+
++++Adapter++++%7C+Implementor
++++-----------%7C---------------
++++Adaptee++++%7C+ConcreteImplementor|code-block|syntax|javascript|1238545|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Bridge is improved Adapter. Bridge includes adapter and adds additional flexibility to it. 
Here is how elements from Ravindra's answer map between patterns:

<pre><code> 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
</code></pre>

blocks|key|1453421|text|Bridge与Adapter非常相似，但当您同时定义抽象接口和底层实现时，我们将其称为Bridge，这意味着不适应外部代码，您是所有代码的设计者，但您需要能够交换不同的实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1453422|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Bridge is very similar to Adapter, but we call it Bridge when you define both the abstract interface and the underlying implementation, means not adapting to external code, you're the designer of all the code but you need to be able to swap out different implementations.

blocks|key|1453502|text|我认为这很简单。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1453503|适配器设计为允许第三方应用程序与您的应用程序一起工作。相反，以便您的应用程序可以与第三方应用程序一起工作。|1453504|使用桥接模式，它应该连接两个或更多应用程序，而不实现适配器。|1453505|事实上，桥是一个接口，两个应用程序将通过它进行交互。作为桥接的一个例子，这些是PHP中的PSR接口。|1453506|示例：|1453507|OtherApp|1453508|<?php

interface+IRequestDataOtherApp+{};
+
interface+IResponseDataOtherApp+{};
+
class+ResponseDataOtherApp+implements+IResponseDataOtherApp+++{

};+
+
class+OtherApp+{
++++public+static+function+request(IRequestDataOtherApp+$requestData):IResponseOtherApp
++++{
++++++++//+code
++++++++return+new+ResponseDataOtherApp+();
++++}
}|code-block|syntax|javascript|1453509|MyApp|1453510|<?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);
//...|1453511|在前面的示例中，我们为每个请求和每个响应实现了2个适配器。如果我们重写示例并尝试实现桥。|1453512|<?php
++++interface+IBridgeResponse+{};|1453513|1453514|<?php
interface+IRequestDataOtherApp+{};
interface+IResponseDataOtherApp+{};
+
class+ResponseDataOtherApp++implements+IBridgeResponse,+IResponseDataOtherApp+++{

};+
+
class+OtherApp+{
++++public+static+function+request(IRequestDataOtherApp+$requestData):IResponseOtherApp
++++{
++++++++//+code
++++++++return+new+ResponseDataOtherApp++();
++++}
}|1453515|1453516|<?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).
*/
}
//...|1453517|在六边形架构中，如果你从一开始就编写了一个应用程序，并且准备好接受另一个正在使用的应用程序的规则，那么端口(接口，契约)就可以充当“桥梁”。否则，您将不得不编写“Adapters”。|1453518|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1B|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1C|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1D|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1E|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|1G|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|1H|8|@]|9|@]|A|$]]|$1|W|3|X|5|N|7|1I|8|@]|9|@]|A|$O|P]]|$1|Y|3|K|5|6|7|1J|8|@]|9|@]|A|$]]|$1|Z|3|10|5|N|7|1K|8|@]|9|@]|A|$O|P]]|$1|11|3|R|5|6|7|1L|8|@]|9|@]|A|$]]|$1|12|3|13|5|N|7|1M|8|@]|9|@]|A|$O|P]]|$1|14|3|15|5|6|7|1N|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|17|$]]

I think it's simple.
The adapter is designed to allow a third party application to work with your application.
Conversely, so that your application can work with third party applications.
Using the bridge pattern, it is supposed to connect two or more applications without implementing an adapter.
In fact, a bridge is an interface through which two applications will interact. As an example of bridging, these are PSR interfaces in PHP.
Example:
OtherApp
<pre class="lang-php prettyprint-override"><code>&lt;?php

interface IRequestDataOtherApp {};
 
interface IResponseDataOtherApp {};
 
class ResponseDataOtherApp implements IResponseDataOtherApp {

}; 
 
class OtherApp {
 public static function request(IRequestDataOtherApp $requestData):IResponseOtherApp
 {
 // code
 return new ResponseDataOtherApp ();
 }
}
</code></pre>
MyApp
<pre class="lang-php prettyprint-override"><code>&lt;?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);
//...
</code></pre>
In the before example, we have implemented 2 adapters per request and per response.
If we rewrite example and try to implement the bridge.
<pre class="lang-php prettyprint-override"><code>&lt;?php
 interface IBridgeResponse {};
</code></pre>
OtherApp
<pre class="lang-php prettyprint-override"><code>&lt;?php
interface IRequestDataOtherApp {};
interface IResponseDataOtherApp {};
 
class ResponseDataOtherApp implements IBridgeResponse, IResponseDataOtherApp {

}; 
 
class OtherApp {
 public static function request(IRequestDataOtherApp $requestData):IResponseOtherApp
 {
 // code
 return new ResponseDataOtherApp ();
 }
}
</code></pre>
MyApp
<pre class="lang-php prettyprint-override"><code>&lt;?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).
*/
}
//...
</code></pre>
In hexagonal architecture, Ports (Interfaces, Contracts) can act as 'Bridges' if you write an application from the very beginning and are ready to accept the rules of another application being used.
Otherwise, you will have to write 'Adapters'.

问网桥模式和适配器模式的区别
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问网桥模式和适配器模式的区别EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问网桥模式和适配器模式的区别
EN