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

怎么会这样? 如果我还记得,策略模式基本上是一种将所使用的逻辑/算法解耦的方法。所以客户机有自己的算法。如果不是,则IAlgorithm应该有一个小的方法集。

因此,algoimplementation类可以更改的唯一原因是

• 如果它实现的算法发生了变化。( 责任/行为的变化 )
• 或者如果ialgoritm发生了变化……除非您在定义接口时出错,否则这种情况很少发生。(这是它自己的公共接口的变化——所以不要认为它违反了SRP。)

事实上,我看到的恰恰相反。策略模式允许您分离两件事情,用于完成某些工作的(潜在)算法和有关这些算法的决策逻辑。

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

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

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

有了对单一责任原则的理解,我不知道实现策略模式的类在哪里违反了SRP。客户机类的目的是实现策略模式,即客户机职责。这些算法的目的是实现它们所负责的逻辑,而单一责任原则说,不要将它们在系统中组合在一起,因为它们会因不同的原因发生变化。那是我的0.02美元。

很好的一点:)我想这更像是一个单一的责任准则,在许多情况下都是有意义的,但对于某些情况也不是,比如战略模式。