所有界面组合都被视为策略模式吗

Question

使用策略模式，我们可以使用接口解耦行为。 行为被移入可以有多个实现的接口。 客户端可以与接口有关系，并且可以在运行时引用其任何实现。

在所有解释中，它都是作为解决与继承相关的问题的解决方案而提到的，其中继承层次结构中不同分支中的两个类需要相同的行为。

我认为即使不存在继承层次结构，我们也可以使用相同的方法将行为与类解耦。引用接口的单个类可以根据它在运行时引用的实现来实现多种行为。

我们可以将这样的用例称为策略模式的实现吗？ 如果是这样，所有与接口的“有关系”是否都被视为策略模式？

Answer 1

在所有解释中，它都是作为解决与继承相关的问题的解决方案而提到的，其中继承层次结构中不同分支中的两个类需要相同的行为。

我刚刚读完了GoF书中对策略的大部分描述，我看不到它提到这方面。也就是说，这似乎是一个足够相关的担忧。

如果将策略模式简化为其退化形式，您将拥有一个

Context

，它在其

Strategy

上调用方法：

public Foo ContextInterface()
{
    return strategy.AlgorithmInterface();
}

只要您有多个（即不止一个）

Strategy

实现，您就可以认为它符合模式描述。

作为一般观察，GoF 中的某些模式比其他模式更具体。策略模式一直让我觉得太通用了，以至于有变得空洞的危险。它几乎是多态性...

的另一个名字

Answer 2

在GoF书中，每种设计模式都使用一致的格式，其中包括意图、动机和适用性。应用模式的原因对于 GoF 至关重要，而且这些原因可能与语法无关。换句话说，出于两个不同的原因应用完全相同的语法（例如单个组合关系）可能是两种不同的模式。

对于作文来说，这是正确的，

...即使不存在继承层次结构，我们也可以使用相同的方法将行为与类解耦。

但从 GoF 的角度来看，如果意图和动机不匹配，那么模式也可能不匹配。

我不会将所有组合关系称为策略，因为这会淡化策略的含义，混淆组合的含义，并破坏通用词汇，而这可以说是设计模式的最大优势。

我习惯将策略模式称为针对缺乏一流功能的语言的面向对象解决方案。我相信这种模式在现代 OO 语言中或多或少已经过时了，它们都支持闭包或 lambda；但是，我不会将所有一流函数称为策略，就像我不会以这种方式引用所有组合一样。

也就是说，策略模式从一般组合关系中脱颖而出的两个特征是 GoF 书第 317 页上的“协作”。

策略和上下文交互以实现所选算法。当调用算法时，上下文可以将算法所需的所有数据传递给策略。或者，上下文可以将自身作为参数传递给策略操作。这使得策略可以根据需要回调上下文。

• 上下文将来自客户端的请求转发到其策略。客户端通常创建一个 ConcreteStrategy 对象并将其传递给上下文；此后，客户只与环境进行交互。通常有一系列 ConcreteStrategy 类供客户选择。

因此，由客户端选择（未预先配置）并利用其组合器的全部或部分的组合对象，看起来更像是策略，而不是仅基于例如组合关系。空方法调用。