应用于设计模式的YAGNI原则有什么意义？

Question

我最近读过“头第一设计模式”。这本书写得很好，值得一读.它通常在开始每一章首先介绍一个问题和一个非常“天真”的解决方案的问题。在下一页中，会提出更多的要求和约束，例如添加更多的特性或更新行为。这本书再次提供了更新的“天真”方法。在某种程度上，当“天真”的方法搞砸了解决方案(事情开始出错)，这本书驱使读者采用一种全新的方法--目标设计模式。

在其他地方，我学到了一个缩写为"YAGNI“的你不会需要的原则，它说：”当你实际需要的时候，永远不要去实现它们，当你只是预见到你需要它们时，永远不要去实现它们。“

我现在想知道，“头第一设计模式”是否以非理性的方式解释了"YAGNI“原则？因为，在某种程度上，给定一组需求，我们应该为问题寻找最简单、最干净的解决方案，对吗？

Answer 1

YAGNI + Design Patterns == Refactoring

对于设计模式，有一种观点主张对模式进行重构而不是从设计到模式。这种观点以“模式重构”一书为例。马丁·福勒在赞同这本书时说，

流行四人帮的...most .不必预先设计，而是随着系统的发展而发展。

这也是Head First Design Patterns采用的方法，并且与YAGNI完全一致。不要做大的预先设计，以决定你可能需要的模式。相反，随着系统的发展，重构为模式。让模式随着时间的推移而出现。

相关：什么应该是第一位的--设计模式还是代码？

Answer 2

YAGNI原则不能说明一个简单的解决方案或一个干净的解决方案。接吻原理描述了这些因素。YAGNI原则的要点是避免开发未使用的功能。使用该原则的主要目的是节省开发时间。

例如，假设您应该将应用程序与外部API集成起来。您可以开发API的客户端组件来实现这一目标。当然，您可以使客户端组件与外部API的所有功能一起工作。这种方式使我们有能力制造出一个强大的通用组件，可以在将来的许多不同的应用程序中使用。但是很可能，您的应用程序目前并不使用每个API功能。这意味着这种方式有几个缺点：

• 你会做出可能永远不会被使用的功能
• 您将把开发时间花在目前无法提供业务价值的功能上。
• 您无法在实际使用中测试未使用的功能。

在这种情况下，开发只使用的功能比开发全部功能更合理。YAGNI原则告诉我们这一点。