战略与桥梁模式 [英] Strategy vs. Bridge Patterns
问题描述
我知道这个问题已经被问过了（例如，桥梁模式与战略模式有什么区别？）。
然而，有人可以解释一下，使用明确的例子，区别是什么，在哪种情况下必须选择一种呢？
桥梁模式区分了一个抽象并且这样一种实现方式使得两者可以独立地变化。我将使用
中的示例
Java中的模式，第1卷：使用UML第二版显示的可重用设计模式的目录
您需要提供访问物理传感器的类，例如秤，速度测量设备等。每个传感器产生一个数字，但数字可能意味着不同的东西。对于尺度，它可能意味着重量和速度测量设备可能意味着速度。
所以你可以先创建一个传感器抽象类来表示所有传感器和各种不同类型的传感器类型。这是一个强大的设计，允许您以后提供更多类型的传感器。
现在假设传感器由不同的制造商提供。您将必须为制造商X创建传感器类别，并为制造商Y创建另一个传感器类别。现在的问题是客户需要知道制造商之间的区别。如果您决定支持第三家制造商...？
解决方案是提供主要的抽象层次结构，即。 Sensor抽象类和子类，如SpeedSensor和WeightSensor等。然后提供将在抽象和实现之间存在的接口（Bridge）。因此，将有一个SensorInterface，WeightSensorInterface和SpeedSensorInterface，它们规定了每个具体传感器类必须提供的接口。抽象不知道实现，而是知道接口。最后，您可以为每个制造商创建一个具体的实现。也就是XSensor，XWeightSensor和XSpeedSensor，YSensor，YSpeedSensor和YWeightSensor。
客户端仅依赖于抽象，但可以插入任何实现。因此，在此设置中，可以更改抽象，而无需更改任何具体类，并实现可以改变，而不用担心抽象。
正如你所看到的，它描述了一种构建你的课程的方法。
<另一方面，策略涉及在运行时改变对象的行为。我喜欢使用具有几种不同类型武器的角色的游戏示例。角色可以攻击，但攻击的行为取决于当时所持有的武器，这在编译时不能被知道。
所以你让武器行为可插拔，并根据需要将其注入字符。因此，行为模式。
这两种模式解决了不同的问题。该策略涉及使算法可互换，而Bridge关心将抽象与实现解耦，从而为同一抽象提供多个实现。也就是说，桥梁与整个结构有关。
以下是可能有用的几个链接：
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
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.
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.
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...?
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.
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屋！
