“ 不要重复自己 DRY”，每个开发者都在他职业生涯的早期就学会了这个口头禅。
对这个原则的共同理解是你不应该复制你的代码。就那么简单。
不要复制，如果你发现重复就重构。
违反此规则的行为将被其他开发人员立即指出为侵犯软件开发最基本的做法之一。
好吧，让我说实话。这种方法完全错误。一个单一的，巨大的，不幸的错误解释是让许多开发人员的生活变得更加艰难。
让我解释一下原因。
你知道DRY原理的原始定义吗？
The *original* DRY principle. And it's about knowledge, not code.
我们对知识管理和一致性有了很好的洞察力，但是将其转化为编码领域则变得无意义。
甚至维基百科在定义DRY方面也很危险。
正如通常所解释的那样，DRY通过将完全不相关的代码部分紧密耦合在一起来伤害代码库。 令人惊讶的是它如何自然地引入了不必要的，偶然的复杂性。
共享内核或库，不断增长的工具库（我们都有一个），继承树。所有这些都是为了避免编写两个相似的代码片段的非理性需求。
有一个应对的解决方案：
重复，重复，重复。
现在让我告诉您为什么默认情况下重复会为您的代码带来相当大的优势.
重复能拖延决策，这是软件开发的黄金。
以后从多个专业化比从单个方法的抽象的重构要容易十倍。
我们的大脑在前一个方向上工作得更好，向后退需要创造性的努力和显着的认知负担，在最坏的情况下，是横向思维。
预先应用DRY，您将构建领域中不存在的抽象。而你正在构建它，以便将部分功能组合在一起，这些功能在不同类之间看起来显然是相同的。
您需要学会轻松地复制/粘贴整个类，并且只更改其命名。
还是不相信？
不同命名空间中的两个相同类很有可能在未来很快发生分歧，即使它们看起来完全相同。
当您预期耦合时，您会错过这种多样化机会并削弱您的模型。
只有当复杂性变得难以管理或模型明确要求时，才应该对抽象进行重构。预防性地执行此操作只会损害您的代码并引入大量意外的复杂性。
这是一种思维方式的改变，需要时间。带上你的，耐心等待。