如果单一职责原则规定每个对象必须有一个单一的变化原因，而根据定义，使用策略模式实现的单一策略类具有多个可以因任意数量原因而改变的方法，那么这是否意味着无法在不违反SRP的情况下实现策略模式？
策略模式是否违反单一职责原则？
4
- plaureano
2
我不太明白你所说的“使用策略模式实现的单个策略类（根据定义）具有多个方法，这些方法可能因为任何原因而发生变化”的意思。你所考虑的定义是什么？ - Ionuț G. Stan
我在思考经典的GOF策略模式定义，它是一个具有一组逻辑相关方法的单个策略类。 - plaureano
5个回答
3
如何做到呢？
如果我没记错，策略模式基本上是一种将正在使用的逻辑/算法解耦的方法。因此客户端拥有m_IAlgorithm接口。IAlgorithm接口应该只包含少量（如果不是一个）方法。
那么AlgoImplementation类可以发生变化的唯一原因是：
- 它实现的算法发生了变化（其责任/行为发生了变化） - 或者如果IAlgoritm发生了更改。这是罕见的，除非您在定义接口时犯了错误。（这是其公共接口的更改——因此不认为这违反了SRP。）
那么AlgoImplementation类可以发生变化的唯一原因是：
- 它实现的算法发生了变化（其责任/行为发生了变化） - 或者如果IAlgoritm发生了更改。这是罕见的，除非您在定义接口时犯了错误。（这是其公共接口的更改——因此不认为这违反了SRP。）
- Gishu
3
我实际上看到的相反。策略模式让你解耦两件事情，一是（可能）用于完成某项工作的算法，二是对这些算法进行决策逻辑。
我不确定你是想要一个既执行条件逻辑，又封装这些算法的类。另外，我并不是说你已经暗示了这一点，但是你没有给出一个例子来说明策略模式会破坏SRP，以及在你的意见中，更好的设计是什么。
- Ionuț G. Stan
2
我最熟悉的单一职责原则的背景是整个系统设计，可以与策略模式相结合，关于系统中组件的分组。使用策略模式定义客户端可互换使用的一组算法，然后可以使用单一职责原则来决定在系统中将客户端和客户端使用的算法分组。如果您的工作仅涉及算法B，则不希望干扰算法A的代码，反之亦然。对于编译型语言，这可能会对重构、版本和部署周期的复杂性产生重大影响。当只需要对算法B进行更改时，为什么要对客户端和算法A、C和D进行版本控制和重新编译呢？
通过对单一职责原则的理解，我不认为拥有实现策略模式的类会违反SRP。客户端类的目的是实现策略模式，这是客户端的责任。算法的目的是实现它们负责的逻辑，而单一职责原则表示不要将它们全部组合在系统中，因为它们将因不同原因而发生变化。这是我的观点。
通过对单一职责原则的理解，我不认为拥有实现策略模式的类会违反SRP。客户端类的目的是实现策略模式，这是客户端的责任。算法的目的是实现它们负责的逻辑，而单一职责原则表示不要将它们全部组合在系统中，因为它们将因不同原因而发生变化。这是我的观点。
- snarkyname77
0
好观点 :) 我想这更像是一个单一职责的指导方针，对于许多情况来说是有道理的，但对于某些情况，比如策略模式，可能并不适用。
- Nils
0
依我看，这取决于观点。 如果你将策略（例如类）视为在运行时决定的算法/逻辑混合物，并且它们彼此非常不同... 是的，有点违反单一职责原则... 但是如果你考虑这个策略类，它是一个解耦实体，封装了整个决策过程，并使其成为一个单一工作类-决定使用哪种算法/逻辑，仅此而已。
- pofqggg
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接