Ano*_*828 4 architecture design-patterns coding-style solid-principles clean-architecture
我向在软件架构领域拥有先进知识的人们提出这个问题。我试图理解与消除代码冗余的想法相关的单一职责原则（SOLID）的想法。我对代码重复的看法是，代码重复是需要修复和消除的错误。实际上，我正在阅读 \xe2\x80\x9cClean Architecture\xe2\x80\x9d （Robert C. Martin），我的看法发生了变化，我有点困惑。
\n\nSRP 强调参与者，因此 Robert Martin 写道 \xe2\x80\x9cA 模块应该对一个且仅一个参与者负责，即参与者\xe2\x80\x9d。作为一个例子，R. Martin 谈到了两个类（模块）。第一个类包含会计部门指定的方法\xe2\x80\x9ccalculatedPay()\xe2\x80\x9d。另一个类包含由另一个参与者（人力资源部门）指定的方法 \xe2\x80\x9creportHours()\xe2\x80\x9d 。这两个函数共享共同的算法（例如小时计算）。自然的方法是将通用算法移至另一个类并消除代码重复。之后，两个函数都会调用新类中的算法。想象一下会计部门需要更改算法（在新类中）。更改后，人力资源部门使用新的（无效）算法。存在问题，并且该问题是由于破坏 SRP 造成的。算法类（模块）对两个参与者负责。另一方面，我们会有不必要的代码重复，这让我焦躁不安。
\n\n也许我关于代码重复的教条方法是错误的，在许多地方使用相同的代码并没有什么错。不是吗？如果我从不同的角度来看它，那么我会看到有多种算法/或者只是多个客户端（参与者）使用的代码部分。有时需要更改所使用的代码。这对我来说是很自然的事情。另一种方式是什么？这就是为什么我不太明白为什么不将重复项放入另一个类中的原因。另一个不同观点的例子，两个类各有一个函数，共享共同的算法，但都由会计部门指定。没有 SRP 中断，因为只有一个参与者仍然存在相同的问题，因为一个更改可能会使另一个类失效。这在某种程度上非常不准确......
\n\n也许我不了解 SRP 及其背后的想法...
\n正如您将在本书后面读到的那样：
\n\n\n\n\n架构师经常陷入 \xe2\x80\x94a 陷阱，这取决于他们对重复的恐惧。在软件中，重复通常是一件坏事。我们不喜欢重复的代码。当代码确实出现重复时，作为专业人士，我们有义务减少和消除它。但存在不同类型的重复。
\n\n存在真正的重复，其中对一个实例的每次更改都需要对该实例的每个副本进行相同的更改。还有错误或意外的重复。如果两个明显重复的代码段沿着不同的路径\xe2\x80\x94演变，如果它们以不同的速率变化，并且出于不同的原因\xe2\x80\x94，那么它们不是真正的重复。
\n
我认为他很好地解释了你的疑问。
\n\n凭借经验和持续关注，您将了解如何使用 SRP 原则以及代码复制。
\n\n我个人的观点是，当您深入研究设计模式和架构时，您将面临一些stackoverflow 用户无法（100%）回答的哲学问题；）
\n