I recently read "Head First Design Patterns". The book is well-written and worth reading. It often starts each chapter by first introducing a problem and a very 'naive' solution to the problem. In next pages more requirements & constraints are raised, for example adding more features or updating behaviors. The book again provides 'naive' approaches to the updates. Up to some point, when 'naive' approaches mess up the solutions (things start going wrong), the book drives readers to a completely new approach - the target design pattern.
Elsewhere I have learned a principle abbreviated "YAGNI" You Aren't Gonna Need It stating that "Always implement things when you actually need them, never when you just foresee that you need them."
I am now wondering, does "Head First Design Patterns" explain things in non-sense way with respect to "YAGNI" principle? Since, up to some point, given a set of requirements we should go for the easiest & cleanest solution to the problem, right?
YAGNI + Design Patterns == Refactoring
There is a perspective on Design Patterns that advocates refactoring to patterns versus designing to patterns. This perspective is exemplified by the book Refactoring to Patterns . In endorsing the book, Martin Fowler states,
...most of the popular Gang of Four patterns... need not be designed in up front, but evolved to as a system grows.
This is the approach that Head First Design Patterns takes as well, and is perfectly consistent with YAGNI. Don't do big-up-front design to decide where you might need patterns. Instead, refactor to patterns as a system evolves. Let the patterns emerge over time.
related: What should come first -- the design pattern or the code?