小编Ano*_*828的帖子

我向在软件架构领域拥有先进知识的人们提出这个问题。我试图理解与消除代码冗余的想法相关的单一职责原则（SOLID）的想法。我对代码重复的看法是，代码重复是需要修复和消除的错误。实际上，我正在阅读 \xe2\x80\x9cClean Architecture\xe2\x80\x9d （Robert C. Martin），我的看法发生了变化，我有点困惑。

SRP 强调参与者，因此 Robert Martin 写道 \xe2\x80\x9cA 模块应该对一个且仅一个参与者负责，即参与者\xe2\x80\x9d。作为一个例子，R. Martin 谈到了两个类（模块）。第一个类包含会计部门指定的方法\xe2\x80\x9ccalculatedPay()\xe2\x80\x9d。另一个类包含由另一个参与者（人力资源部门）指定的方法 \xe2\x80\x9creportHours()\xe2\x80\x9d 。这两个函数共享共同的算法（例如小时计算）。自然的方法是将通用算法移至另一个类并消除代码重复。之后，两个函数都会调用新类中的算法。想象一下会计部门需要更改算法（在新类中）。更改后，人力资源部门使用新的（无效）算法。存在问题，并且该问题是由于破坏 SRP 造成的。算法类（模块）对两个参与者负责。另一方面，我们会有不必要的代码重复，这让我焦躁不安。

也许我关于代码重复的教条方法是错误的，在许多地方使用相同的代码并没有什么错。不是吗？如果我从不同的角度来看它，那么我会看到有多种算法/或者只是多个客户端（参与者）使用的代码部分。有时需要更改所使用的代码。这对我来说是很自然的事情。另一种方式是什么？这就是为什么我不太明白为什么不将重复项放入另一个类中的原因。另一个不同观点的例子，两个类各有一个函数，共享共同的算法，但都由会计部门指定。没有 SRP 中断，因为只有一个参与者仍然存在相同的问题，因为一个更改可能会使另一个类失效。这在某种程度上非常不准确......

也许我不了解 SRP 及其背后的想法...