这不是您要寻找的DRY

发生了严重错误。我们采用了有关知识管理的有见地的原则，并将其转变为代码废话。

“ 不要重复自己 ”。每个受人尊敬的开发人员都在其职业生涯的早期就学习了这一口头禅。

对该原则的普遍理解是，您不应复制您的代码。就那么简单。

不要复制模式。如果找到重复的副本，则进行重构。

违反此规则的其他开发人员将立即指出，这是对软件开发的最基本实践之一的侵犯。

好吧，让我说实话。 这种方法是完全错误的 。一个单一的，巨大的，不幸的误解正在使许多开发人员的生活变得更加艰难。

让我解释一下原因。

您知道DRY原理的原始定义吗？

我们对知识管理和一致性有了很好的了解，并将其转变为代码废话。

甚至维基百科在定义DRY方面也很尴尬。只需查看DRY vs WET解决方案段落即可。我什至不知道与这种原则有什么关系。

众所周知，DRY通过将完全不相关的代码部分紧密耦合在一起而损害了代码库。它自然地引入了不必要的，偶然的复杂性，这令人惊奇。

共享的内核或库，不断增长的Util命名空间（我们都有一个），继承树。所有这些都是出于非理性的需要避免编写两个相似的代码。

我们对知识管理和一致性有了很好的了解，并将其转变为代码废话。

但是有一个解决方案。

现在让我告诉您为什么默认情况下复制会为您的代码带来可观的优势。

复制可以延迟决策 。这就是软件开发中的黄金。

与其他方式相比，将其从多个专业重构为一个抽象要容易十倍。

我们的大脑在前一个方向上表现更好。向后走需要创造性的努力和巨大的认知负担。在最坏的情况下，即使是横向思考。

通过预先应用DRY，您正在构建域中不存在的抽象。并且您正在构建它是为了将部分功能组合在一起，这些功能在不同的类之间看起来只有相同 。

相似的类是相似的，它们不是同一件事。它们不能达到相同的目的。它们不能在相同的用例上运行。

您需要学习习惯于按字面意义复制/粘贴整个类，并且仅更改其名称空间。

我什至在不同模块之间复制值对象。这是一个例子：

代码库的不同部分。不同的用例。不同的接口。

如此不同，分离，不相关的类。

即使最初看起来完全一样，不同名称空间中的两个相同的类也很有可能在将来很快分开。

当您预期耦合时，您会错过这种多元化的机会并削弱您的模型 。

仅当复杂性变得难以控制或模型明确要求抽象时，才应进行重构。预防性地这样做只会损害您的代码并引入大量的意外复杂性。

如果您不使用DRY，大脑会欺骗您很多次，使您以为一切都会变得一团糟，您会感到惊讶。

您已经习惯了这种做法，以至于当您放弃它时，您会感到非常满意，但确实感到惊讶，因为一切都很好。

您不会再碰到重复的代码，重复本身将是代码库中的最后一个问题。

这是一种观念转变，需要时间。采取你的，耐心点。

消除在不同类之间共享代码的需求。

您不需要用于处理对象集合的自定义共享库（PHP开发人员，我正在寻找您）。

复制每个模式，因为下次您将需要它时，它将不会像以前那样用在相同的用例中。类似的也许，但不相同。

切换到这种复制思维方式后，很少有时间实际上需要将某个东西保存在一个地方而不是被复制，您会知道的。 你会感觉到的 。

只有在那一刻，您才能开始抽象到另一个模型。您将看到一致性边界，该边界将建议您是否将所有内容放在一起。

这是您要寻找的真正的DRY。