策略与桥接模式 [英] Strategy vs. Bridge Patterns
问题描述
我知道之前有人问过这个问题(例如，桥接模式和策略模式有什么区别?).
I know this question's been asked before (e.g., What is the difference between the bridge pattern and the strategy pattern?).
但是，有人可以用清晰的例子解释一下有什么区别以及在什么情况下必须选择一个而不是另一个吗?更少的概念理论，更实际的现实生活"场景将不胜感激.
However, could someone please explain, using clear-cut examples, what the difference is and in what sorts of cases one must be selected over the other? Less conceptual theory, more practical "real-life" scenarios would be appreciated.
推荐答案
桥接模式区分抽象和实现，使两者可以独立变化.我将使用
The Bridge Pattern makes a distinction between an abstraction and an implementation in such a way that the two can vary independently. I will use the example from
Java 中的模式，第 1 卷:使用 UML 说明的可重用设计模式目录，第二版
Patterns in Java, Volume 1: A Catalog of Reusable Design Patterns Illustrated with UML, Second Edition
您需要提供访问物理传感器的类，例如秤、速度测量设备等.每个传感器产生一个数字，但数字可能意味着不同的东西.对于秤，它可能意味着重量，对于速度测量设备，它可能意味着速度.
You need to provide classes that access physical sensors such as found in scales, speed measuring devices etc. Each sensor produces a number but the number could mean different things. For the scale it could mean the weight and for the speed measuring device it may mean speed.
因此，您可以从创建 Sensor 抽象类开始，以表示所有传感器和不同类型传感器的各种子类之间的共性.这是一种稳健的设计，可让您在未来提供更多类型的传感器.
So you can start by creating a Sensor abstract class to represent the commonality between all sensors and various subclasses for the different types of sensors. This is a robust design allowing you to provide many more types of sensors in the future.
现在假设传感器由不同的制造商提供.您必须为制造商 X 和制造商 Y 创建一个传感器类的层次结构.现在的问题是客户需要知道制造商之间的差异.如果您决定支持第三家制造商...?
Now suppose that sensors are provided by different manufacturers. You will have to create a heirarchy of sensor classes for manufacturer X and another for manufacturer Y. The problem now is that the clients would need to know the difference between the manufacturers. And if you decide to support a third manufacturer...?
解决方案是提供主要的抽象层次结构，即.Sensor抽象类和子类，如SpeedSensor和WeightSensor等.然后提供将存在于抽象和实现之间的接口(Bridge).所以会有一个 SensorInterface、WeightSensorInterface 和 SpeedSensorInterface，它们规定了每个具体传感器类必须提供的接口.抽象不知道实现，而是知道接口.最后，您可以为每个制造商创建一个 concreate 实现.即 XSensor、XWeightSensor 和 XSpeedSensor、YSensor、YSpeedSensor 和 YWeightSensor.
The solution is to provide the main abstraction heirarchy, ie. the Sensor abstract class and sub classes such as SpeedSensor and WeightSensor and so on. Then provide the interface (Bridge) that will exist between the abstraction and the implementation. So there will be a SensorInterface, WeightSensorInterface and SpeedSensorInterface, which dictates the interface that each concrete sensor class must provide. The abstraction does not know about the implementation, rather it knows about the interface. Finally, you can create an concreate implementation for each manufacturer. That is, XSensor, XWeightSensor and XSpeedSensor, YSensor, YSpeedSensor and YWeightSensor.
客户端仅依赖于抽象，但可以插入任何实现.因此，在此设置中，可以在不更改任何具体类的情况下更改抽象，并且可以更改实现而无需担心抽象.
Clients depend only on the abstraction but any implementation could be plugged in. So in this setup, the abstraction could be changed without changing any of the concrete classes, and the implementation could be changed without worrying about the abstraction.
如您所见，这描述了一种构建类的方法.
As you can see this describes a way to structure your classes.
另一方面，策略与在运行时改变对象的行为有关.我喜欢用一个游戏的例子来说明一个角色拥有几种不同类型的武器.角色可以攻击，但是攻击的行为取决于角色当时持有的武器，这在编译时是无法知道的.
The Strategy on the other hand is concerned with changing the behaviour of an object at run time. I like to use the example of a game with a character that possesses several different types of weapons. The character can attack but the behaviour of attack depends on the weapon that the character is holding at the time, and this cannot be known at compile time.
因此，您使武器行为可插入并根据需要将其注入角色.因此是一种行为模式.
So you make the weapon behaviour pluggable and inject it into the character as needed. Hence a behavioral pattern.
这两种模式解决了不同的问题.该策略涉及使算法可互换，而 Bridge 涉及将抽象与实现解耦，以便您可以为同一抽象提供多个实现.也就是说，桥梁与整个结构有关.
These two patterns solve different problems. The strategy is concerned with making algorithms interchangeable while the Bridge is concerned with decoupling the abstraction from the inplementation so that you can provide multiple implementations for the same abstraction. That is, the bridge is concerned with entire structures.
以下是一些可能有用的链接:
Here are a few links that might be useful:
这篇关于策略与桥接模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
