What is the point of YAGNI principle applied to design patterns?

Question

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?

Answer 1

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?

Answer 2

YAGNI principle doesn't tell about an easy solution or a clean solution. KISS principle describes those factors. The main point of YAGNI principle is to avoid development of unused functionality. The primary goal of this principle using is saving of development time.

For example, let's imagine you should integrate your application with external API. You develop a client component of API to achieve this goal. Of course, you can make the client component that will work with all of the functionality of external API. This way gives to the ability to make the great universal component that can be used in many different applications in the future. But probably, your application doesn't use each of the API functionality in present. It means this way has several drawbacks:

• you'll make functionality that maybe never be used
• you'll spend the development time to functionality that doesn't give business value in present.
• you couldn't test unused functionality in real usage.

In this case, the development of only used functionality is more rational than the development of full functionality. YAGNI principle tells us about it.