Рон Джеффрис заявляет: "Всегда выполняйте вещи, когда вы действительно нуждаетесь в них, никогда, когда вы просто предвидите, что они вам нужны".
И все же, если бы я программировал подсистему, скажем, в С#, тогда я потратил бы немало времени на рассмотрение моего дизайна OO и внедрение больших шаблонов в качестве шаблона стратегии для инкапсуляции вещей, которые, вероятно, будут меняться в будущее.
Вступают ли эти две позиции в конфликт, и как правильно получить баланс?
Мой выбор всегда заключался в выборе шаблона дизайна, если это имеет смысл прямо сейчас. Если в требованиях указывается, что будет 3 способа обработки данных, тогда я могу выбрать стратегию, если они укажут, что будет один путь, и я, вероятно, не буду беспокоиться, если у меня нет очень веских оснований полагать, что в ближайшее время будет добавлено больше в будущем. Это вообще не конфликтует с XP: выберите реализацию, которая имеет смысл сейчас, и если код не примет эту реализацию, то реорганизуйте раздел, который нужно изменить, чтобы принять желаемую реализацию.
в соответствии с шаблоном проектирования. не пропустите весь путь, пока вам не понадобится.
Мое предложение - смотреть еще на один шаг, но не на два.
Предположим, вам нужно написать программное обеспечение для журнала, который управляет 100 статьями. Одна из особенностей вашего программного обеспечения - найти статью, основанную на имени автора. Поскольку существует только 100 статей, нет смысла использовать карты или хэши; просто переверните все журналы и сравните автора.
Однако существует большая вероятность того, что ваше программное обеспечение будет использоваться в следующем году для управления 1000 статьями, или 10000 или 1 миллион статей, а затем вам может понадобиться карта или хэш. Так почему бы не отобразить/хеш статьи на имя автора уже в данный момент? Это то, что я имею в виду, глядя еще на один шаг.
Теоретически ваше приложение может также использоваться для поиска статей на основе слова в контенте. Вы можете добавить функциональность N-грамм, а псевдонимы слов - нечеткие поиски и т.д. Но если эта функциональность в настоящее время не используется, зачем ее применять? Это то, что я имею в виду, не глядя еще на два шага дальше.
В теории, разница между поиском одного шага или двух шагов дальше, может быть трудно сделать и, вероятно, зависит от типа вашего приложения, от отрасли, в которой вы работаете, от того, как ваше программное обеспечение продается,...
В любом случае, используйте свое воображение, но не заходите слишком далеко.
Да. Представляем шаблон, подобный стратегии, только для того, чтобы абстрагироваться от того, что может изменить конфликты с Рон "вам это не понадобится"
Шаблоны проектирования дают вам словарь механизмов, которые вы могли бы использовать, но если вы делаете XP, вы будете реализовывать шаг за шагом - даже если вы достаточно уверены, что вам понадобится какой-то шаблон.
Иногда мы начинаем с шаблона в виду и обнаруживаем, что работа поэтапно не получается так, как мы думали, и заканчиваем тем, что лучше подходит для дизайна. Образцы были предназначены только для руководства.
Я могу настоятельно рекомендовать Стиву Фримену и Нату Прайс "Растущее программное обеспечение, управляемое тестированием", как отличную книгу о том, как это сделать.