DRY 没有单一代码？

Question

我不想重复自己（DRY），但我不能有一段代码。例如，这里的代码重复了 3 次，并且有相同的错误：

class StarWars : Movie
{
   //Calculate "base ^ exponent"
   public float Power(float base, float exponent)
   {
      return (base * exponent);
   }
}

class Customer: Object
{
   //Calculate "base ^ exponent"
   public float Exponential(float base, float exponent)
   {
      return (base ^ exponent);
   }
}

class Student: Person
{
   //Calculate "base ^ exponent"
   public float CalculateExpoential(float base, float exponent)
   {
      return CalculateExponential(2.7182818, exponent * Ln(base));
   }
}

现在理想情况下，我会将这个通用函数提取到它自己的帮助程序中：

class LibraryOfHelperCode
{
    public static float Exponentiation(float base, float exponent)
    {
       return Exp(2.71828183, base * Ln(exponent));
    }
}

并将现有代码转换为使用它：

class StarWars : Movie
{
   //Calculate "base ^ exponent"
   public float Power(float base, float exponent)
   {
      return LibraryOfHelperCode.Exponentiation(base, exponent);
   }
}

class Customer: Object
{
   //Calculate "base ^ exponent"
   public float Exponential(float base, float exponent)
   {
      return LibraryOfHelperCode.Exponentiation(base, exponent);
   }
}

class Student: Person
{
   //Calculate "base ^ exponent"
   public float CalculateExpoential(float base, float exponent)
   {
      return LibraryOfHelperCode.Exponentiation(base, exponent);
   }
}

值是，现在我已经从其中提取了重复的代码

• 将幂
• 指数
• CalculateExpoential

转换为单个函数。这意味着如果存在任何错误，只需修复一次。在这种情况下这是好事，因为有一个错误：

   public float CalculateExpoential(float base, float exponent)
   {
      //19971012: Oops, should be natrual log of base, not exponent
      return Exp(2.71828183, exponent * Ln(base));    
   }

几年后：

   public float CalculateExpoential(float base, float exponent)
   { 
      //19990321: Oops, need to handle when exponent is zero
      if (exponent == 0)
         return 1.0;

      //19971012: Oops, should be natrual log of base, not exponent
      return Exp(2.71828183, exponent * Ln(base));    
   }

然后：

   public float CalculateExpoential(float base, float exponent)
   { 
      //19990321: Oops, need to handle when exponent is zero
      if (exponent == 0)
         return 1.0;

      //20040523: Another special case
      if (Base = 0.0) && (Exponent > 0.0) then
         return 0.0; // 0**n = 0, n > 0

      //19971012: Oops, should be natrual log of base, not exponent
      return Exp(2.71828183, exponent * Ln(base));    
   }

最后：

   public float CalculateExpoential(float base, float exponent)
   { 
      //20101027: Microsoft just release a method in .NET framework 4.0 that does
      //what we need. Use it:
      return Math.Pow(base, exponent);
   }

每个人都得到了修复。另一方面，我不能保证任何一个增量修复都不会破坏现有代码。

想象一个人正在打电话：

char ps = Math.Trunc(Exponential(ProblemSize, ProblemComplexity));

并且从未预料到该值会大于 128。他错了。虽然代码一直错误：但它碰巧可以工作。

现在我来修复问题，突然代码由于溢出和/或环绕而崩溃。

---

我今天面临的问题是 DRY 通用代码的更改会影响使用它的所有地方。唯一可接受的（政治上的）解决方案是为使用它的每个可执行文件/模块/命名空间/类保留库类的副本。

消除任何干燥感。

有什么办法摆脱这个混乱吗？当我不能重复自己，但继续获得修复和改进，因为它们被添加到单个 DRY 代码中时？

---

我的意思是...我应该共享代码，但在每个版本中对其进行分支吗？但政治上的问题是没有人希望代码全部被反向集成。

Answer 1

仅当您更改库的界面时，您的程序才会中断。如果更改库的实现会破坏您的程序，则您可能将程序与库的绑定过于牢固。该程序不应依赖于图书馆的内部运作。
如果您不断更改库的界面并破坏您的项目，则可能需要花费更多时间来设计库。

您还应该对您的库使用版本控制。针对库的特定分支/版本构建代码。如果库接口发生较大变化，并且您不想更新现有项目，请为新接口创建一个新分支，新项目可以使用该分支，而旧项目可以继续使用旧分支。可以针对一个分支编写错误修复并合并到另一分支中。

Git 特别擅长这类事情。使用子模块将您的项目链接到库的特定提交。

Answer 2

我认为在每个使用此功能的类中都有一个辅助类并不会真正消除干燥性。即使您确实在各处重复包含/声明帮助器，但这也使您不必重复任何进一步的功能。

您所做的任何架构更改（例如继承或助手）都将不得不影响以某种方式使用它们的所有内容，如果继承没有意义，那么与某种 Date 对象或 Helper 组合可能是一个不错的选择要走的路。

Answer 3

唯一可以接受的（政治上的）
解决方案是保留一份副本
每个人的图书馆课程
可执行文件/模块/命名空间/类
使用它。

DRY 是特定软件解决方案的设计原则，但并不总是在跨程序集或域边界时有意义。领域驱动设计的方法使用诸如有界域上下文之类的概念来处理跨程序集和项目的可共享代码问题。

虽然您用通用语言向我们提出了一个问题，但该问题没有通用的解决方案。

---

Dan G 对组合提出了很好的观点（使主根对象包含一个可以实现所需行为而无需使用实现的子对象）。只要有意义，微软的架构指南就提倡这种方法而不是继承。

---

如果可以的话，我会投票给 Meager 和 Dan G，他们都提出了很好的评论。

Answer 4

看来您的问题不在于干燥性，而在于依赖项的版本控制。因此，您所遇到的情况是，您的辅助类（带有错误修复）是每个主类的依赖项。但是，只有一个主要类实际上引用了包含修复程序的帮助器类的版本。另外两个类可以自由选择何时升级到改进的帮助器类（通过依赖关系管理过程）。

StarWars-1.0.0.jar -> Helpers-1.0.0.jar
Empire-1.0.1.jar -> Helpers-1.0.1.jar
Jedi-1.0.0.jar -> Helpers-1.0.0.jar

助手团队发布更新来修复问题，其他团队决定何时升级。

你仍然是 DRY，但你可以掌控变化。

Answer 5

看来这里的部分问题是需求变化的正常结果。三段代码依赖于“今天”这一共同的业务概念。有些事情发生了变化，“今天”不再有单一的概念。一些代码需要继续基于银河标准日历的当前理解，而一些代码现在需要基于本地恒星系统日历的更灵活的概念（谈论本地化头痛！）。

这只是发生的正常事情。用 SRP 术语来说，由单段代码处理的单一职责现在变成了需要由单独代码段处理的两项职责，因为已经确定了新的变更向量。是时候重构了。

Piskvor 提出了一种解决该问题的方法，该方法在某些情况下效果很好。如果您使用 IOC 容器或至少某种形式的 DI，另一种方法是引入 IHelper 接口（希望它从一开始就存在）。然后，您所需要的只是接口的新实现和一些配置，以便为每个系统连接正确的实现。

wllmsaccnt 也是正确的，DRY 通常不适合跨越您不想创建依赖项的系统边界。事实上，不同的系统有不同的产品负责人，这几乎是一个事实上的变革向量，主张有一个单独的代码库，即使一个系统一开始是另一个系统的分支。共享代码库意味着共享所有权，如果这在政治上不现实，那么在技术上就不合适。