В чем смысл принципа YAGNI, применяемого к шаблонам проектирования?
Я недавно прочитал "Head First Design Patterns". Книга хорошо написана и заслуживает прочтения. Часто каждая глава начинается с представления проблемы и очень "наивного" решения проблемы. На следующих страницах предъявляются дополнительные требования и ограничения, например, добавляется больше функций или обновляется поведение. В книге снова представлены "наивные" подходы к обновлениям. До некоторой степени, когда "наивные" подходы портят решения (вещи начинают идти не так, как надо), книга подталкивает читателей к совершенно новому подходу - целевому шаблону проектирования.
В другом месте я выучил принцип, сокращенно "ЯГНИ", который вам не нужен, утверждая, что "Всегда воплощайте вещи в жизнь, когда они вам действительно нужны, никогда, когда вы просто предвидите, что они вам нужны".
Теперь я задаюсь вопросом, объясняет ли "Шаблоны проектирования с первого взгляда" бессмысленное отношение к принципу "ЯГНИ"? Поскольку до определенного момента, учитывая набор требований, мы должны искать самое простое и чистое решение проблемы, верно?
2 ответа
YAGNI + Design Patterns == Refactoring
Существует точка зрения на шаблоны проектирования, в которой рекомендуется проводить рефакторинг шаблонов вместо проектирования шаблонов. Эта перспектива иллюстрируется книгой " Рефакторинг к паттернам". Поддерживая книгу, Мартин Фаулер утверждает,
... большинство популярных паттернов Gang of Four... не должны разрабатываться заранее, а развиваться по мере развития системы.
Это тот подход, который использует Head First Design Patterns, и он полностью соответствует YAGNI. Не занимайтесь дизайном заранее, чтобы решить, где вам могут понадобиться шаблоны. Вместо этого, рефакторинг к шаблонам по мере развития системы. Пусть шаблоны появляются со временем.
по теме: что должно быть на первом месте - шаблон проектирования или код?
Принцип YAGNI не говорит о простом решении или чистом решении. Принцип KISS описывает эти факторы. Суть принципа YAGNI - избежать развития неиспользуемой функциональности. Основная цель использования этого принципа - экономия времени разработки.
Например, давайте представим, что вам следует интегрировать ваше приложение с внешним API. Вы разрабатываете клиентский компонент API для достижения этой цели. Конечно, вы можете создать клиентский компонент, который будет работать со всеми функциями внешнего API. Этот способ дает возможность сделать отличный универсальный компонент, который может быть использован во многих различных приложениях в будущем. Но, вероятно, ваше приложение не использует все функции API в настоящее время. Это означает, что этот способ имеет несколько недостатков:
- вы сделаете функциональность, которая, возможно, никогда не будет использоваться
- вы потратите время на разработку функциональности, которая не дает бизнес-ценности в настоящее время.
- Вы не можете проверить неиспользованную функциональность в реальном использовании.
В этом случае разработка только используемой функциональности более рациональна, чем разработка полной функциональности. Принцип ЯГНИ говорит нам об этом.