策略与桥接模式

Question

我知道以前有人问过这个问题(例如，What is the difference between the bridge pattern and the strategy pattern?)。

但是，有没有人可以用清晰的例子来解释一下，这是什么区别，以及在什么情况下必须选择一个而不是另一个？少一些概念性的理论，多一些实际的“现实生活”场景会更受欢迎。

Answer 1

Bridge模式在抽象和实现之间进行了区分，使得两者可以独立地变化。我将使用下面的示例

Java语言中的

模式，第1卷:用统一建模语言说明的可重用设计模式目录，第二版

您需要提供访问物理传感器的类，例如在天平、速度测量设备等中发现的。每个传感器产生一个数字，但该数字可能意味着不同的事情。对于天平，它可能意味着重量，而对于测速装置，它可能意味着速度。

因此，您可以首先创建一个Sensor抽象类来表示所有传感器和不同类型传感器的各种子类之间的共性。这是一个健壮的设计，允许您在未来提供更多类型的传感器。

现在假设传感器由不同的制造商提供。您必须为制造商X创建传感器类的层次结构，为制造商Y创建另一个传感器类的层次结构。现在的问题是，客户端需要知道制造商之间的区别。如果你决定支持第三家制造商呢？

解决方案是提供主要的抽象层次结构，即。传感器抽象类和子类，如SpeedSensor和WeightSensor等。然后提供将存在于抽象和实现之间的接口(Bridge)。因此，将有一个SensorInterface、WeightSensorInterface和SpeedSensorInterface，它们规定了每个具体传感器类必须提供的接口。抽象并不知道实现，而是知道接口。最后，您可以为每个制造商创建一个concreate实现。即XSensor、XWeightSensor和XSpeedSensor、YSensor、YSpeedSensor和YWeightSensor。

客户端仅依赖于抽象，但任何实现都可以插入。因此，在此设置中，可以在不更改任何具体类的情况下更改抽象，并且可以更改实现，而无需担心抽象。

正如您所看到的，这描述了一种构造类的方法。

另一方面，策略关注的是在运行时更改对象的行为。我喜欢用一个角色拥有几种不同类型武器的游戏为例。角色可以攻击，但攻击行为取决于角色当时持有的武器，而这在编译时是无法获知的。

所以你让武器行为可插拔，并根据需要将其注入到角色中。因此形成了一种行为模式。

这两种模式解决了不同的问题。该策略关注的是使算法可互换，而Bridge关注的是将抽象与实现解耦，以便您可以为同一抽象提供多个实现。也就是说，桥梁与整个结构有关。

以下是一些可能有用的链接：

1. Bridge Pattern
2. Strategy Pattern

Answer 2

我可以说这很难解释。许多使用它并理解它的人很难向新手解释它。

对于像我这样以类比的方式思考的人：

策略模式

所以战略是一种--一维的概念。想一想可供选择的一维策略数组。

示例1:管道工的工具

策略模式就像一个水管工，他有各种工具来疏通管道。这项工作每次都是一样的，那就是疏通管道。但他选择的完成此任务的工具可能会因情况而异。也许他会尝试一个，如果不起作用，他会尝试另一个。

在这个类比中，“疏通管道”是实现其中一个策略的方法。蛇刷、强力螺旋和排水管是具体的策略，管道工是包含方法的类(在大多数图中标记为“上下文”)。

​

​

示例2:多位螺丝刀

或者你可以想象一下多位螺丝刀上的可互换螺丝刀。它们应该在运行时被换掉，以适应手头的工作，这就是搞砸一些东西。

​

​

桥接模式

所以桥是一个二维的概念。想象一下，一个维度(行)是需要实现的方法的列表，第二个维度(列)是实现每个方法的实现者。

示例1:应用程序和设备

桥接模式就像一个人有许多通信方式(电子邮件、文本、google语音、电话、skype)和许多设备，他们可以通过这些不同的方式进行通信- PC、平板电脑和智能手机。

各种通信方式(电子邮件、文本、电话)将是抽象接口上的方法，我们称其为"CommunicationDevice“。在此模式中，CommunicationDevice是实现者。这个类比中的每个设备(PC、平板电脑、智能手机)都是实现所有这些方法(电子邮件、文本、电话)的ConcreteImplementor。

​

​

示例2: Odbc数据库驱动程序和odbc函数

另一个现成的桥接示例是Windows的odbc或oledb数据库驱动程序模块。它们都在相同的标准“数据库驱动程序”接口上实现各种方法，但它们以不同的方式实现该接口。即使您使用相同的数据库，例如Sql Server，仍然有不同的驱动程序可以与Sql Server通信，尽管在幕后以不同的方式进行通信。

示例3:实现者(列)实现方法(行)

​

​

Answer 3

策略模式

此模式允许执行的算法独立于使用它的客户端而变化。即，它允许在运行时选择许多算法中的一种，而不是针对给定的站点执行固定的算法。这包括将算法从其宿主类中移除，并将其放入单独的类中。

例如，假设一个人想要从一个城市旅行到另一个城市，那么他有几个选择:乘坐公交车，租用汽车，赶火车，等等。因此，每种选择的交通方式都会变成一个单独的算法来执行。选择的运输模式将取决于在运行时决定的各种因素(成本、时间等)。换句话说，选择执行的策略将是即时决定的。

另一个例子，假设有人想要实现一个基于strategy的Sorts的SortedList类(主控制器)。策略是用于排序的方法(如MergeSort、QuickSort)。

与桥接模式的比较

主要的区别(即使两个模式具有相同的UML)是不同于桥模式(它是一个结构模式)，策略模式是一个行为模式。结构模式建议如何组合或关联或继承对象以形成更大的对象，即它们专注于对象组合。而行为模式处理算法或业务逻辑(而不是对象创建本身)，即它们关注对象之间的协作。

请注意，大多数算法可以实现为只需要创建单个实例的静态或单例类(即，不是每次设置策略时都调用new )。

仔细看看这两种模式的实现，就会发现在桥模式中，先创建对象的具体实现，然后再创建调用。

// Set implementation and call
// i.e. Returns (creates) the concrete implementation of the object, 
// subsequently operation is called on the concrete implementation
ab.Implementor = new ConcreteImplementorA(); 
ab.Operation();

而在策略模式的情况下，人们不会直接使用算法的具体实现，而是创建策略应该在其中执行的上下文，

// Set the context with a strategy
// i.e. Sets the concrete strategy into the context, concrete implementation of the class not 
// directly available as a data object (only the algorithm is available).    
context = new Context (new ConcreteStrategyA());     
context.contextInterface();

// Strategy can be reused instead of creating a new instance every time it is used.
// Sort example
MergeSort mergeSort = new MergeSort();
QuickSort quickSort = new QuickSort();
...
context = new Context (mergeSort);
context.Sort();
...
context = new Context (quickSort);
context.Sort();
...
context = new Context (mergeSort);
context.Sort();