虚假代码重复

通常的本能是删除您在代码中看到的所有代码重复。但是，我发现自己处于一种重复的幻象之中。

为了更详细地描述这种情况：我正在开发一个Web应用程序，并且大多数视图基本上是相同的-它们显示用户可以滚动并从中选择的项目列表，包含所选项目的第二个列表以及“保存” ”按钮以保存新列表。

在我看来，这个问题很容易。但是，每个视图都有其自己的怪癖-有时您需要重新计算某些内容，有时您必须存储一些其他数据，等等。这些我通过在主逻辑代码中插入回调挂钩来解决。

有这么多，它是越来越少维护的，因为我需要为所有基本功能提供回调的观点之间的微小差异，主要逻辑开始看起来像回调调用的一个巨大的序列。最后，我没有节省任何时间或代码，因为每个视图都有自己执行的代码-全部在回调中。

问题是：

• 差异是如此之细，以至于代码在所有视图中看起来几乎都是相似的，
• 有这么多的差异，当你看细节，代码是不是有一点相像

我应该如何处理这种情况？
具有完全由回调调用组成的核心逻辑是否是一个好的解决方案？
还是我应该复制代码并降低基于回调的代码的复杂性？

最终，您必须对是否组合相似代码以消除重复进行判断。

似乎有一种不幸的趋势，将“不要重复自己”这样的原则作为必须始终死记硬背的规则。实际上，这些不是通用规则，而是可以帮助您考虑和开发良好设计的准则。

作为生活中的一切，您必须考虑收益与成本。多少重复的代码将被删除？该代码重复多少次？编写更通用的设计将花费多少精力？您将来可能会开发多少代码？等等。

在不知道您的特定代码的情况下，尚不清楚。也许有一种更优雅的方法来删除重复项（例如LindaJeanne建议的方法）。或者，也许根本就没有足够的真实重复来保证抽象。

对设计的关注不足是一个陷阱，但也要提防过度设计。

请记住，DRY与知识有关。这两段代码看起来是相似，相同还是完全不同并不重要，重要的是，在这两个代码中都可以找到有关您系统的相同知识。

一条知识可能是事实（“与目标值的最大允许偏差为0.1％”），或者可能是您过程的某些方面（“此队列永远不会包含三个以上的项目”）。实际上，它是源代码中编码的任何一条信息。

因此，当您确定是否应删除重复项时，请询问其是否是知识重复项。如果不是这样，则可能是偶然的重复，将其提取到某个常见位置会在以后要创建类似组件（其中明显重复的部分不同）时引起问题。

您是否考虑过使用策略模式？您将拥有一个View类，其中包含由多个视图调用的通用代码和例程。View类的子级将包含特定于那些实例的代码。它们都将使用您为View创建的通用接口，因此差异将被封装且一致。

变革的潜力是什么？例如，我们的应用程序有8个不同的业务领域，每个领域有4个或更多用户类型的潜力。根据用户类型和区域自定义视图。

最初，这是使用相同的视图完成的，并在此进行了一些检查，以确定是否应显示不同的内容。随着时间的流逝，某些业务领域已决定做完全不同的事情。最后，我们基本上将每个业务区域的每个功能迁移到一个视图（在ASP.NET MVC的情况下为局部视图）。并非所有业务领域都具有相同的功能，但是如果一个人想要另一个拥有的功能，则该领域将拥有自己的视图。对于代码的理解以及可测试性而言，它不再那么麻烦。例如，对一个区域进行更改不会导致对另一个区域进行不必要的更改。

如@ dan1111所述，它可以归结为判断。随着时间的流逝，您可能会发现它是否有效。

一个问题可能是您只为单个功能级别提供了一个接口（理论接口，而不是语言功能）：

A(a,b,c) //a,b,c are your callbacks or other dependencies

而不是取决于需要多少控制权的多个级别：

//high level
A(a,b,c)
//lower
A myA(a,b)
B(myA,c)
//even lower
A myA(a)
B myB(myA,b)
C myC(myB,c)
//all the way down to you just having to write the code yourself

据我了解，您仅公开高级界面（A），隐藏了实现细节（此处还有其他内容）。

隐藏实现细节有好处，而您刚刚发现了一个缺点-控制是有限的，除非您为直接使用低级接口可能会为每件事显式添加的功能。

因此，您有两个选择。您要么只使用低级接口，要么使用低级接口，因为高级接口的维护工作量太大，或者公开高低级接口。唯一明智的选择是提供高层和低层接口（以及两者之间的所有内容），假设您要避免使用冗余代码。

然后，当您编写另一本书时，请查看到目前为止已编写的所有可用功能（无数种可能性，取决于您决定哪些可以重复使用）并将它们组合在一起。

在几乎不需要控制的地方使用单个对象。

当需要进行一些怪异操作时，请使用最低级别的功能。

它也不是很黑白。也许您的高水平课程可以合理地涵盖所有可能的用例。也许用例变化如此之大，以至于最低级别的原始功能就足够了。由您自己来找到余额。

已经有其他有用的答案。我会加我的。

复制不好，因为

1. 它使代码混乱
2. 它会使我们对代码的理解混乱，但最重要的是
3. 因为如果你改变的东西在这里，你也必须改变的东西存在，你可以忘掉/引入错误/ ... ...，这是很难永远不会忘记。

因此，重点是：您并不是为了消除重复或因为有人说重复很重要而消除了重复。之所以这样做，是因为您想减少错误/问题。以您的情况看来，如果您在视图中更改了某些内容，则可能不需要在所有其他视图中更改完全相同的行。因此，您具有明显的重复，而不是实际的重复。

另一个重要的观点是，永远不要像Joel所说的那样，仅从原则上重写某些目前仅在原则上起作用的东西（您可能已经听说过他。。。）。因此，如果您的意见有效，请逐步进行改进，不要沦为“任何软件公司都可能犯的最严重的战略错误”。