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