我向软件架构领域的高级知识人员解决这个问题。我试图理解与消除代码冗余的想法有关的单一职责原则（SOLID）的想法。我对代码重复的看法是，代码重复是错误的，需要修复和消除。实际上，我正在阅读“清洁建筑”（罗伯特·C·马丁），我的看法发生了变化，我有些困惑。
SRP强调演员，因此罗伯特·马丁（Robert Martin）写到“一个模块应该对一个演员负责，而只有一个演员负责”。例如，R。Martin谈论两个类（模块）。第一类包含会计部门指定的方法“ calculatedPay（）”。另一个类包含由另一个参与者（人力资源部门）指定的方法“ reportHours（）”。这两个函数共享通用算法（例如小时计算之类的东西）。自然的方法是将通用算法移至另一类并消除代码重复。之后，两个函数都将在新类中调用该算法。假设会计部门需要更改算法（在新类中）。更改后，人力资源部门将使用新的（无效）算法。存在一个问题，该问题是由破坏SRP引起的。算法类（模块）负责两个角色。另一方面，我们将有不必要的代码重复，这使我烦躁不安。
也许我对代码重复的教条方法是错误的，并且在很多地方拥有相同的代码没有错。是不是如果我从不同的角度看待它，那么我会发现有多种算法/或者只是多个客户端（角色）使用的代码部分。有时需要更改所使用的代码。对我来说这是自然的事情。那是另一种方式呢？这就是为什么我不太理解为什么不将重复项放在另一个班级的原因。另一个具有不同视图的示例，两个类各自具有一个功能，它们共享通用算法，但两者均由会计部门指定。没有SRP中断，因为通过相同的问题仅存在一个参与者，因为一个更改可以使另一个类无效。这有点不准确...
也许我不了解SRP及其背后的想法...
答案 0 :(得分：2)
您将在本书的后面部分阅读
建筑师通常会陷入陷阱-陷阱取决于他们对重复的恐惧。在软件中，复制通常是一件坏事。我们不喜欢重复的代码。当代码真正被复制时，我们将以减少和消除代码的专业人员为荣。但是有不同类型的重复。
有 true重复，其中对一个实例的每次更改都必须对该实例的每个副本进行相同的更改。然后是错误或意外重复。如果两个明显重复的代码段沿着不同的路径发展-如果它们以不同的速率变化并且由于不同的原因-那么它们不是真正的重复。
我认为他很好地解释了您的疑问。
通过经验和持续的关注，您将了解如何将SRP原则与代码复制一起使用。
我的个人看法是，随着您对设计模式和体系结构的深入研究，您将面临一些哲学问题，这些问题不能（100％）由stackoverflow用户回答；）
答案 1 :(得分：0)
SRP只是一个营销术语，它试图推广更古老（定义更好）的 cohesion 和 coupling 概念。我建议只要有关于SRP的问题，就回到这些术语上。
这些都没有提及任何有关代码复制的内容，但它们确实暗示“数据”应始终与所有相关的行为伴随。
这意味着，实际上不会有执行相同操作的“重复代码”，因为它无法访问与原始数据相同的数据（因为数据始终被封装）。
但是，可能存在重复的代码，它们执行的操作基本上相同，但是对于不同的概念，它具有自己的数据，但可能相似。这些事情也会因不同的原因而发生变化，因此与鲍伯叔叔所说的一致。
答案 2 :(得分：0)
我想补充：没有设计决定必须是静态的。
在某个时间点提取重复的代码并从单个位置共享它可能是一个不错的决定。随着需求的变化，在专门针对一个用户进行更改之前，可能有必要重新考虑该决定并再次“复制”代码。
答案 3 :(得分：0)
几个学期前，我也面临着同样的问题。 了解SRP的重要性和核心概念也是理解冗余代码。
首先，您必须熟悉冗余代码的概念。让我们举一个非常简单的例子：
Actor1使用A类：
仅负责计算Actor1和Actor1的给定特定输入，然后返回结果。
Actor2将使用B类：
根据Actor2的特定输入，这有责任计算不同的东西，然后返回结果。但是，在设计类时，我们意识到部分计算包含与A类所包含的相同的代码。
这是一个示例，其中如果我们继续进行设计，则类B将包含冗余代码，因为它将包含重复的代码，而该代码已经存在于类A中。
解决方案：
根据SOLID（开放/封闭原则），我们不允许返回并更改A类并允许B类使用它。原因是我们不允许删除/修改A类中存在的任何代码。原因是我们可能会破坏Actor1或其他未知actor的代码。
因此，我们改为编写扩展了A类的C类，因此可以通过C类使用特定的计算，因此将来可能会同时用于B类和其他任何计算方法。
希望这回答了您的问题！