Конфликтует ли XP с использованием шаблонов проектирования?

Question

Рон Джеффрис заявляет: «Всегда воплощайте вещи в жизнь, когда они вам действительно нужны, а не тогда, когда вы просто предвидите, что они вам нужны».

И все же, если бы я программировал подсистему, скажем, на C #, тогда я бы потратил немало времени, рассматривая свой дизайн ОО и внедряя отличные шаблоны в качестве шаблона Стратегии для инкапсуляции вещей, которые «вероятно, будут'изменить в будущем.

Есть ли конфликт между этими двумя позициями, и как мне найти правильный баланс?

Answer 1

рефакторинг к шаблону проектирования. не идите весь путь, пока вам не нужно.

Answer 2

Мой выбор всегда заключался в том, чтобы выбрать шаблон дизайна, если он имеет смысл сейчас. Если в требованиях указано, что будет 3 способа обработки данных, тогда я могу выбрать стратегию, если они укажут, что будет один способ, то я, вероятно, не буду беспокоиться, если у меня нет веских оснований полагать, что в ближайшее время будет добавлено еще в будущем. Это совершенно не противоречит XP: выберите реализацию, которая имеет смысл сейчас, и если код не примет эту реализацию, выполните рефакторинг раздела, который необходимо изменить, чтобы принять реализацию, которую вы хотите.

Answer 3

Да : Представляем шаблон, подобный стратегии, просто для того, чтобы абстрагировать что-то, что может изменить конфликты с высказыванием Рона "тебе это не понадобится"

Шаблоны проектирования дают вам словарь механизмов, которые вы могли бы использовать, но если вы работаете с XP, вы реализуете шаг за шагом - даже если вы достаточно уверены, что вам понадобится какой-то шаблон.

Иногда мы начинаем с шаблона и находим, что работа пошагово не работает так, как мы думали, и в итоге мы получаем другой дизайн, который подходит лучше. Образцы должны были быть только ориентиром.

Я настоятельно рекомендую Стиву Фриману и Нату Прайсу «Растущее программное обеспечение на основе тестов» как отличную книгу о том, как это сделать.

Answer 4

Я предлагаю заглянуть на шаг вперед, а не на два.

Предположим, вам нужно написать программное обеспечение для журнала, который управляет 100 статьями.Одной из особенностей вашего программного обеспечения является поиск статьи на основе имени автора.Поскольку статей всего 100, использовать карты или хэши не имеет смысла;просто переберите все журналы и сравните автора.

Однако есть большая вероятность, что ваше программное обеспечение будет использовано в следующем году для управления 1000 статей, или 10000, или 1 миллионом статей, и тогда вам может понадобитьсякарта или хеш.Так почему бы не отобразить / хэшировать статьи об имени автора уже в этот момент?Это то, что я имею в виду, когда заглядываю на шаг дальше.

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

Теоретически, разницу между взглядом на один шаг или два шага дальше, может быть трудно сделать, и, вероятно, это зависит от типа вашего приложения, отрасли.вы работаете, как ваше программное обеспечение коммерциализируется, ...

В любом случае, используйте свое воображение, но не заходите слишком далеко.