4

如果单一职责原则规定每个对象都必须有一个更改的理由，并且使用策略模式（根据定义）实现的单个策略类具有多个可以因多种原因而更改的方法，这是否意味着不可能实现不违反 SRP 的策略模式？

4

5 回答 5

3

怎么会这样？如果我记得，策略模式基本上是一种解耦正在使用的逻辑/算法的方法。所以客户端有 m_IAlgorithm。IAlgorithm 应该有一小组方法，如果没有的话。

所以 AlgoImplementation 类可以改变的唯一原因是

  • 如果它实现的算法发生变化。（改变其责任/行为）
  • 或者如果 IAlgoritm 发生变化……除非您在定义接口时犯了错误，否则这种情况很少见。（它改变了它自己的公共接口——所以不要认为它违反了 SRP。）
于 2009-04-28T07:31:06.183 回答
3

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

我不确定你是否宁愿有一个类，它既可以对要使用的算法执行条件逻辑，也可以包含这些算法。另外，我并不是说你暗示了这一点，但你没有给出一个例子，说明策略会破坏 SRP 以及在你看来什么是更好的设计。

于 2009-04-28T07:42:28.980 回答
2

我最熟悉的单一职责原则的上下文是在整体系统设计中，并且可以补充关于系统内组件分组的策略模式。

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

有了对单一职责原则的这种理解，我看不出有一个实现策略模式的类在哪里违反了 SRP。客户端类的目的是实现策略模式，即客户端的职责。算法的目的是实现它们负责的逻辑，单一责任原则是不要在系统内将它们全部组合在一起，因为它们会因不同的原因而变化。那是我的 0.02 美元。

于 2011-04-18T13:31:19.613 回答
0

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

于 2009-04-28T07:20:08.787 回答
0

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

于 2021-07-10T18:03:05.240 回答