В чем смысл принципа YAGNI, применяемого к шаблонам проектирования?

Question

Я недавно прочитал "Head First Design Patterns".Книга хорошо написана и заслуживает прочтения.Часто каждая глава начинается с представления проблемы и очень «наивного» решения проблемы.На следующих страницах предъявляются дополнительные требования и ограничения, например, добавляется больше функций или обновляется поведение.В книге снова представлены «наивные» подходы к обновлениям.До некоторой степени, когда «наивные» подходы портят решения (вещи начинают идти не так, как надо), книга подталкивает читателей к совершенно новому подходу - целевому шаблону проектирования.

В другом месте я выучил сокращенный принцип »ЯГНИ " Ты не собираешься это делать заявляя, что" Всегда реализуй вещи, когда они тебе действительно нужны, а не когда ты просто предвидишь, что они тебе нужны. "

Мне вот интересно«Шаблоны дизайна Head First» объясняют вещи бессмысленным образом относительно принципа «YAGNI»?Поскольку до определенного момента, учитывая набор требований, мы должны искать самое простое и чистое решение проблемы, верно?

Answer 1

YAGNI + Design Patterns == Refactoring

Существует перспектива проектирования шаблонов, которая предлагает рефакторинг для шаблонов, а не проектирование для шаблонов.Эта перспектива иллюстрируется книгой Рефакторинг к паттернам .Поддерживая книгу, Мартин Фаулер утверждает, что

... большинство популярных паттернов Gang of Four ... не нужно разрабатывать заранее, а развивать по мере роста системы.

Это подход, который использует Head First Design Patterns, и он полностью соответствует YAGNI.Не занимайтесь дизайном заранее, чтобы решить, где вам могут понадобиться шаблоны.Вместо этого, рефакторинг к шаблонам по мере развития системы.Пусть шаблоны появляются со временем.

related: Что должно быть на первом месте - шаблон дизайна или код?

Answer 2

Принцип YAGNI не говорит о простом или чистом решении. KISS принцип описывает эти факторы.Суть принципа YAGNI - избежать развития неиспользуемой функциональности.Основная цель использования этого принципа - экономия времени разработки.

Например, давайте представим, что вам следует интегрировать ваше приложение с внешним API.Вы разрабатываете клиентский компонент API для достижения этой цели.Конечно, вы можете создать клиентский компонент, который будет работать со всеми функциями внешнего API.Этот способ дает возможность сделать отличный универсальный компонент, который может быть использован во многих различных приложениях в будущем.Но, вероятно, ваше приложение не использует все функции API в настоящее время.Это означает, что у этого способа есть несколько недостатков:

• вы сделаете функциональность, которая никогда не будет использоваться
• вы потратите время на разработку функциональности, которая не дает бизнес-ценности вподарок.
• вы не можете протестировать неиспользованную функциональность в реальном использовании.

В этом случае разработка только используемой функциональности более рациональна, чем разработка полной функциональности.Принцип Ягни говорит нам об этом.