Выбор правильного шаблона дизайна

Я всегда осознавал важность использования шаблонов дизайна. Мне интересно, как другие разработчики выбирают наиболее подходящий. Используете ли вы ряд характеристик (например, блок-схему), чтобы помочь вам принять решение?

Например:

Если объекты связаны, но мы не хотим указывать конкретный класс, рассмотрим абстрактный

Когда создание экземпляров оставлено производным классам, рассмотрим Factory

Необходим доступ к элементам статистического объекта последовательно, попробуйте Iterator

или что-то подобное?

Ключевое заблуждение в современном мире кодирования заключается в том, что шаблоны являются строительными блоками. Вы берете AbstractFactoryздесь и Flyweightтам и, возможно, Singletonтам, и соединяете их вместе с XML и presto, у вас есть работающее приложение.

Они не.

Хм, этого было недостаточно.

Шаблоны не являются строительными блоками

Так-то лучше.

Шаблон - это то, что вы используете, когда обнаруживаете, что у вас есть проблема - вам нужна некоторая гибкость, которую обеспечивает шаблон, или на которую вы наткнулись, когда делаете небольшой язык в файле конфигурации и говорите «подождите». минутку, остановитесь, это мой собственный интерпретатор, который я пишу - это известная и решенная проблема, используйте шаблон интерпретатора ".

Но обратите внимание, что это то, что вы обнаруживаете в своем коде, а не то, с чего вы начинаете. Создатели Java не говорили «О, мы поместим Flyweight в Integer», а скорее осознали проблему с производительностью, которую можно решить с помощью flyweight .

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

Начинать с паттерна - все равно что искать решение и искать проблему. Это плохо: это ведет к чрезмерному проектированию и, в конечном итоге, к негибкости дизайна.

Когда вы пишете код, когда вы понимаете, что пишете Фабрику, вы можете сказать: «Ага, это фабрика, которую я собираюсь написать», и использовать свои знания знания шаблона Фабрики, чтобы быстро написать следующий фрагмент: код, не пытаясь заново открыть шаблон фабрики. Но вы не начинаете с «У меня здесь есть класс, я напишу фабрику для него, чтобы он мог быть гибким» - потому что он не будет.

Вот выдержка из интервью с Эрихом Гаммой ( Гамма, Хелм, Джонсон и Виссидес ): Как использовать шаблоны проектирования :

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

Лучшей справкой для того, «что использовать, когда», вероятно, является страница Википедии по шаблону разработки программного обеспечения - раздел «Классификация и список» описывает категорию, в которой находится каждый шаблон, и что он делает. Там нет блок-схемы; описание там, вероятно, лучшее, что вы найдете в виде короткого фрагмента «что использовать, когда».

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

Поэтому любая попытка перечислить их все по своей сути является неполной. Вы находите один, выясняете, как его использовать, и тогда это в конечном итоге становится второй натурой, и вам не нужно думать о том, как или когда использовать его снова (пока кто-нибудь не попросит вас объяснить это).

Я спрашиваю себя:

1. Какую проблему я пытаюсь решить?
2. Какой шаблон проектирования программного обеспечения (если таковой имеется) наиболее точно решает ту же проблему или обеспечивает логический путь к решению моей проблемы?
3. Нужна ли мне дополнительная абстракция (и сложность), которую предоставляет шаблон, или это чрезмерная инженерия для моей конкретной проблемы? Может ли проблема быть решена более простым и эффективным способом без шаблона?

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