Любой может прочитать книгу GoF, чтобы узнать, какие шаблоны проектирования и как их использовать, но каков процесс определения, когда шаблон дизайна решает проблему? Знает ли образец шаблона дизайн, или есть способ выяснить, как шаблон можно использовать для изменения дизайна?
Другими словами, существуют ли шаблоны для шаблонов?
Предполагается, что шаблоны проектирования должны обеспечивать структуру, в которой проблемы могут быть решены. При решении реальной проблемы вы должны рассмотреть множество крошечных вариантов решения этой проблемы, чтобы увидеть, подходит ли какой-либо шаблон дизайна. В частности, вам, вероятно, понадобится обобщить вашу проблему или ее решение, чтобы создать образец дизайна.
Ответ: это искусство. Знание шаблонов проектирования, безусловно, является важным шагом. Один из способов привыкнуть к подобным вещам - изучить приложения шаблонов проектирования, а не только шаблоны. Увидев много разных приложений одного шаблона, вы с течением времени сможете улучшить отображение карты на шаблон.
Я бы очень рекомендовал прочитать Head First Design Patterns от O'Reilly. Это объясняет, как эти шаблоны можно использовать в реальном мире.
Я бы также добавил, что не пытайтесь слишком много разрабатывать дизайн с учетом шаблонов. Более того, найдите "запахи кода", которые шаблон может помочь решить.
Поверните вопрос: шаблон mtch, который вы должны сделать, - это "какой шаблон подходит для моей проблемы". Рассмотрим действительно простой шаблон, находящий элемент в массиве. в C это что-то вроде
TYPE_t ary[SIZE] = // ... gets initialized somehow
size_t ix ; // Your index variable
for(ix=0; ix < SIZE; ix++){
if (ary[ix] == item) {
return ix ;
}
}
Вы не смотрите на код и думаете, "где я могу его использовать", вы смотрите на проблему и говорите "знаю ли я, как найти элемент в массиве?"
С более обширными шаблонами действительно работает одинаково. У вас должно быть много копий структуры данных, которая не меняется часто - это заставляет думать "мухи". Вы хотите что-то, что живет по обе стороны границы сети, вы думаете, что прокси.
Когда вы изучаете шаблоны, особенно GoF, спрашивайте себя: "Какие ситуации требуют этого шаблона? Я видел этот шаблон раньше? Что я мог использовать для предыдущей работы? Где я могу найти пример этого в моем собственной жизни?"
Есть основная концепция, лежащая в основе шаблонов, которые большинство людей не испытывает. Не думайте о них как о структурах данных или о алгоритмах.
Вместо этого подумайте о своем коде как о том, как люди отправляют сообщения, например, передавая заметки или отправляя письма друг другу. Каждый объект является "человеком".
Способ организации "людей" и шаблонов, которые они используют для отправки сообщений друг другу, - это шаблоны.
Шаблоны проектирования? Вы впитываетесь в них!
Там нет ничего особенного в дизайне, они просто шаблоны дизайна. Все разработки используют шаблоны проектирования. Существует определенный набор шаблонов проектирования в объектно-ориентированном программировании, которые считаются в целом желательными и становятся каноническими шаблонами проектирования. Но есть также много нежелательных или иных безразличных шаблонов дизайна (например, дизайн анти-шаблонов), а также неоткрытые и/или недокументированные шаблоны.
Вы не можете избежать использования шаблонов при программировании. Но вы можете больше узнать о шаблонах, которые вы используете, и о том, когда определенные шаблоны полезны, а когда нет. Изучение канонических шаблонов дизайна из GoF book поможет, так как узнает о запахи кода и рефакторинг. Там нет ни одного правильного ответа, когда нужно использовать конкретный шаблон дизайна или дизайна, вам нужно создать опыт использования и реализации, чтобы узнать, когда и где использовать этот шаблон.
Опыт. Изучите образцы и реальные примеры их использования. Каждый раз, когда у вас есть дизайнерское решение, подумайте, будет ли шаблон, который вы знаете, применить к нему. Со временем вы улучшаетесь, и вы обнаружите новые способы применения шаблонов к более широкому кругу проблем.
Еще одна отличная книга, которую я нашел:
Рефакторинг для шаблонов
Показывая, когда, где и как вы можете изменить существующий код на шаблоны, это дало мне гораздо лучшее понимание понятий и возможность определить, где они могут быть использованы.
Риан ван дер Мерве написал отличную статью об этом для Smashing Magazine в июне 2012 года. Вот несколько важных пунктов.
Шаблоны проектирования полезны по двум причинам:
van der Merwe рекомендует рассматривать шаблоны разбиения, когда:
Если вы знаете шаблоны, они становятся инструментами в вашем наборе инструментов. Когда вы смотрите на задачу, вы выбираете из своих инструментов. В этот момент у вас должна быть довольно хорошая идея, какой инструмент лучше всего подходит для данной проблемы. Здесь формулы перестают работать, и вы на самом деле выполняете инженерные работы.
Как вы узнали, когда использовать оператор if?
Я уподобляю это тому, потому что его более крупная конструкция, которую вам нужно знать во всех деталях, прежде чем вы сможете эффективно использовать ее. Оператор if решает класс проблем, требующих ветвления. Мостовая схема решает класс проблем. Я действительно не рассматриваю их по-другому.
Я согласен, что недостаточно изучать шаблоны. Проблема с большинством книг заключается в том, что они не предоставляют реальных примеров. Я слышал, что Head First Design Patterns, как некоторые из предложенных ранее, является хорошим.
Другое дело, что большинство книг намеренно не зависит от языка, что может быть как хорошим, так и плохим для вас. Однако важно понимать шаблон в целом, не менее важно знать, как его реализовать хорошо. Я столкнулся с книгой под названием С# 3.0 Design Patterns, которая посвящена примерно равным чернилам для обоих этих неотделимых аспектов.
У меня был такой же вопрос, когда я впервые столкнулся с шаблонами дизайна. Я оценил концепции, но не знал, когда и как их применять. Мой первоначальный подход заключался в поиске применимости на этапе проектирования. Когда у вас есть блок-диаграмма и полу-четкие обязанности для каждого блока, его не слишком сложно взять на себя ответственность и перекрестно ссылаться на них с достойным справочником. Здесь упоминалось несколько хороших, но GoF должен быть в вашем списке. Следующим шагом будет поиск улучшений в дизайне, основанный на том, что вы видите в шаблонах.
Концепция шаблона проектирования была взята из структурной инженерии, как и многие практики в разработке программного обеспечения. Если вы планируете строить структуру, то необходимо принять решения о том, как построить эту структуру для достижения поставленных целей. При принятии этих решений у вас будет набор требований к работе. Это может быть нечто простое, так как мост должен иметь возможность поддерживать X тонн за один раз или иметь определенную силу растяжения, чтобы обеспечить достаточное движение на ветру и т.д. Архитектор использовал бы предварительные знания о других сборках, чтобы сделать эти варианты дизайна. Он/она вряд ли попытается решить проблему с нуля.
Разработка программного обеспечения и шаблонов проектирования абсолютно одинаковы. Это просто общие решения общих проблем. Если вы знаете шаблоны проектирования, тогда, когда вы работаете над дизайном, и для определенной части системы требуется что-то, что соответствует шаблону проектирования, а затем используйте его. Не пытайтесь подгонять систему вокруг шаблона проектирования, вставляйте шаблоны дизайна в свою систему (где они подходят). Просто попробуйте подумать о них как о наборе решений для сокращения объема проектных работ, которые вам нужно выполнить, и будьте осторожны над чрезмерной разработкой своих решений, чтобы втиснуть столько шаблонов дизайна, сколько сможете. Это просто поможет сделать ваше решение недостижимым и, вероятно, довольно затруднительным.
Шаблон проектирования представляет собой общее описание о том, как решить общую проблему. Мы должны обратить внимание на 2 вещи:
Во-первых, это Общее описание; это не конкретное решение, и это не полный рецепт, это просто описание того, как будет выглядеть решение, чтобы приблизиться к общей проблеме.
Во-вторых, проблема заключается в проблеме :. Это означает, что эта проблема встречалась много раз раньше, и с течением времени люди разработали описание того, как идеальное решение может быть применено к этому обычно повторяющаяся проблема.
Итак, если вы сталкиваетесь с новой проблемой, которая не является обычной, попробуйте не использовать шаблоны проектирования для ее решения или, по крайней мере, не создавайте шаблоны проектирования для вашего инструмента, чтобы просто решить любую проблему, с которой вы сталкиваетесь.