design-patterns - 违反 DRY 原则一定是不好的吗？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭10 年前。

Improve this question

我一直在讨论DRY(不要重复自己)原则，也称为DIE(重复是邪恶的)并且有投票认为任何简单的代码重复总是一种邪恶。我想听听您对以下几点的看法:

1. future 不确定。假设我们在两个地方有相同的代码。关键是，这两个地方只是附带的含义。它们将来有可能会有所不同，因为它们的上下文和语义不同。从这些地方进行抽象并不便宜，如果其中一个地方发生变化，从抽象中解开包装将更加昂贵。
2. 可读性。存在涉及多个变量或步骤的复杂计算。在代码的其他位置还有另一个代码，其某些部分相同。问题是，如果我们去掉公共(public)部分，计算的可读性就会降低，并且创建的抽象将很难给它一个描述性的名称。更糟糕的是，如果算法的某些部分将来会像第 1 点那样发生变化。

上述情况是否是放弃抽象过程并仅保留重复代码以应对 future 更改风险或只是提高可读性的充分理由？

Answer 1

这些都是违反 DRY 的完全正当理由。我应该添加第三个:性能。这很少是什么大问题，但它可以产生影响，而抽象可能会降低速度。

实际上，我会添加第四个:通过更改可能已经正常工作的代码库的两个(或更多)部分来浪费时间并可能引入新的错误。如果您不需要，并且将来可能不会节省任何或太多时间，那么是否值得花费成本去弄清楚如何抽象这些东西？

通常，重复的代码并不理想，但肯定有令人信服的理由允许它，可能包括比OP和我自己建议的更进一步的原因。