问题描述
使用策略模式，我们可以使用接口来解耦行为。 行为被移动到可以有多个实现的接口中。 客户端可以与接口建立关系，并且可以在运行时引用它的任何实现。
在所有的解释中，它被提及作为解决与继承相关的问题的解决方案，其中继承层次结构中不同分支的两个类需要相同的行为。
我认为即使不存在继承层次结构，我们也可以使用相同的方法将行为与类分离。具有对接口的引用的单个类可以根据它在运行时引用的实现实现多种行为。
我们可以将这些用例称为策略模式的实现吗？ 如果是，是否所有与接口的关联都被视为策略模式？
解决方法
在所有的解释中，它被提及作为解决与继承相关的问题的解决方案，其中继承层次结构中不同分支的两个类需要相同的行为。
我刚刚阅读了大部分 GoF 书中对 Strategy 的描述，我看不出它提到了这方面。也就是说，这似乎是一个足够相关的问题。
如果你将策略模式简化为它的退化形式，你有一个 Context 在它的 Strategy 上调用一个方法：
public Foo ContextInterface()
{
return strategy.AlgorithmInterface();
}
只要您有多个（即不止一个）Strategy 实现，您就可以争辩说它符合模式描述。
作为一般观察，GoF 中的某些模式比其他模式更具体。策略模式一直让我印象深刻，因为它是如此通用，以至于它处于空洞的危险之中。它几乎是多态性的另一个名字...
,在 GoF 书中，每个设计模式都使用一致的格式，包括意图、动机和适用性。应用模式的原因对 GoF 至关重要，原因可能与语法无关。换句话说，出于两个不同的原因应用完全相同的语法（例如单个组合关系）可能是两种不同的模式。
构图确实如此，
...即使不存在继承层次结构，我们也可以使用相同的方法将行为与类分离。
但从 GoF 的角度来看，如果意图和动机不匹配，那么模式也可能不匹配。
我不会将所有组合关系都称为策略，因为这会淡化策略的含义，混淆组合的含义，并破坏可以说是设计模式最大优势的常用词汇。
对于缺乏一流功能的语言，我习惯于将策略模式称为面向对象的解决方案。我相信这种模式在现代 OO 语言中或多或少已经过时了，它们都支持闭包或 lambdas；然而，我不会将所有一流的功能称为策略，就像我会以这种方式引用所有组合一样。