战略模式是否违反单一责任原则？

Question

如果单一责任原则规定每个对象必须有一个改变的理由，并且使用策略模式实现的单个策略类（根据定义）有多种方法可以因任何原因而改变，这是否意味着它是在不违反SRP的情况下无法实施战略模式？

Answer 1

怎么样？ 如果我重新收集的策略模式基本上是一种解耦所使用的逻辑/算法的方法。所以Client有m_IAlgorithm。如果不是一个，IAlgorithm应该有一小组方法。

因此，AlgoImplementation类可以更改的唯一原因是

• 如果它实现的算法有变化。 （改变其责任/行为）
• 或者如果IAlgoritm发生变化..除非你在定义界面时犯了错误，否则这种情况很少见。 （它改变了自己的公共界面 - 所以不要认为它违反了SRP。）

Answer 2

我实际上看到了相反的情况。策略模式可以让你解耦两件事，用于完成某些工作的（潜在）算法和关于这些算法的决策逻辑。

我不确定你是否有一个类，它既可以使用哪种算法来处理条件逻辑，也可以包含这些算法。另外，我并不是说你暗示了这一点，但是你没有举一个例子，其中策略会破坏SRP，在你看来，这是一个更好的设计。

Answer 3

我最熟悉单一责任原则的背景是整体系统设计，并且可以对系统内组件分组的策略模式进行补充。

使用策略模式定义客户端可互换使用的一组算法，然后可以使用单一责任原则来确定客户端的分组位置以及客户端在系统中使用的算法。如果您的工作完全在算法B中，您不希望打扰算法A的代码，反之亦然。对于编译语言，这会对重要因素，版本和部署周期的复杂性产生重大影响。为什么版本并重新编译客户端和算法A，C和D时，只需要更改算法B的位置。

通过对单一责任原则的理解，我没有看到实现策略模式的类在哪里违反了SRP。客户端类的目的是实现策略模式，即客户端的责任。算法的目的是实现他们负责的逻辑，单一责任原则说不要将它们全部组合在一起，因为它们会因为不同的原因而改变。那是我的0.02美元。

Answer 4

好点:)我想这更像是一个单一的责任指南，对许多情况都有意义，但有些情况也没有，比如策略模式..

Answer 5

取决于 IMO 的观点。 如果您将策略（例如类）视为由运行时决定的算法/逻辑的混合物，并且它们彼此完全不同......是的，这有点违反单一职责模式......但是如果你认为关于这个策略类，它是一个解耦实体，它封装了整个决策制定并使其成为一个单一的工作类 - 决定将要使用哪种算法/逻辑，仅此而已