我最近阅读了“Head First Design Patterns”。这本书写得很好，值得一读。它通常通过首先介绍一个问题和一个非常“幼稚”的问题解决方案来开始每一章。在接下来的页面中，提出了更多要求和约束，例如添加更多功能或更新行为。这本书再次提供了更新的“幼稚”方法。在某种程度上，当“幼稚”的方法弄乱了解决方案（事情开始出错）时，这本书会驱使读者采用一种全新的方法——目标设计模式。
在其他地方，我学到了一个缩写为“YAGNI”的原则，你不需要它，它指出“总是在你真正需要的时候实施，永远不要在你预见到你需要它们的时候实施。”
我现在想知道，关于“YAGNI”原则，“Head First Design Patterns”是否以无意义的方式解释事物？因为，在某种程度上，给定一组要求，我们应该为问题寻找最简单和最干净的解决方案，对吧？
YAGNI + Design Patterns == Refactoring
有一种关于设计模式的观点主张重构模式而不是设计模式。《重构到模式 》一书就是这种观点的例证。Martin Fowler 在赞同这本书时说，
......大多数流行的四人帮模式......不需要预先设计，而是随着系统的发展而演变。
这也是 Head First Design Patterns 采用的方法，并且与 YAGNI 完全一致。不要做大的预先设计来决定你可能需要模式的地方。相反，随着系统的发展重构模式。让模式随着时间的推移而出现。
YAGNI 原则并没有说明简单的解决方案或干净的解决方案。KISS原则描述了这些因素。YAGNI 原则的要点是避免开发未使用的功能。使用此原则的主要目标是节省开发时间。
例如，假设您应该将您的应用程序与外部 API 集成。您开发 API 的客户端组件来实现此目标。当然，您可以使客户端组件与外部 API 的所有功能一起使用。这种方式使我们能够制造出可用于未来许多不同应用的通用组件。但很可能，您的应用程序目前并未使用每个 API 功能。这意味着这种方式有几个缺点：
在这种情况下，只开发使用的功能比开发完整的功能更合理。YAGNI 原理告诉我们。