Как вы применяете шаблоны проектирования?

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

Когда вы впервые решите, что будете использовать шаблоны дизайна? Все ли вы решаете шаблоны проектирования перед кодированием?
Существуют ли какие-либо DP-адреса, которые вы применяете после того, как закончите кодирование (небольшие рефакторинги)? Используете ли вы DP при сохранении кода?
Каковы шаблоны проектирования, которые преимущественно применяются во время проектирования?
Каковы DP, которые вы применяете при настройке/рефакторинге кода?
Есть ли какие-либо подсказки в коде (технические не функциональные вещи), которые предполагают, что вы должны применять DP (например, слишком много ifs, двойная отправка, многопоточность)? Если да, можете ли вы назвать DP и их точки останова?
Используете ли вы какие-либо микро-DP, которые заставляют вас чувствовать себя хорошо о коде, который вы написали (хотя другие ненавидят вас за него: p)?

Edit:
Я хотел бы добавить, что я читаю DP через "Head First Design Patterns" и хотя это одна из лучших книг для понимания шаблона. Я не думаю, что смог перенести примеры Pizza в реальные сценарии.

Я думаю, что это одна из самых влиятельных книг в DP, но у нас все еще есть книга, которая может перечислять различные популярные бизнес-сценарии, которые требуют определенного шаблона наряду с этим шаблоном. Думаю, это знание по-прежнему неявно. Такая книга была бы очень красивой быстрой ссылкой, вы не думаете:))

Ответ 1

Это зависит от того, как вы пишете код. Если это большой проект, который я решаю перед кодированием, то после того, как я начну писать код, если я заметлю места, где должны использоваться шаблоны проектирования, я реорганизую код.
Да, как упоминалось ранее.
в 99,99% случаев: Factory Образец, Singleton (Как и все, я использую его во многих местах, потому что его просто реализовать, и на практике я стараюсь удалить его при рефакторинге кода). Затем: Пул объектов (если у меня есть ресурсы, которые я хочу повторно использовать), некоторые из моих проектов - это игры, и мне нужно хорошее управление ресурсами), Стратегия и Template Method (потому что они отлично подходят для развязки и хорошо служат для упрощения расширения кода). Тогда Адаптер - это то, что нужно использовать, когда у вас есть библиотека, которую вы хотите использовать, не полагаясь на нее (развязка).
То же, что и выше, если я еще не использовал их. Он работает и наоборот. Если я не нахожу причину использования шаблона проектирования, я удаляю его или пропущу его во время написания кода (это происходит все время с singleton и время от времени с фабриками. Иногда я использую factory, который также является singleton, чтобы предоставить мне те, которые должны были быть объектами с одиночными именами, не уверен, что это разумно, но это работает для меня).
Единственный подсказку в коде, которую я могу представить, это количество ссылок, которые у вас есть для класса. Вы также можете использовать PMD, jDepend и Правила архитектуры, чтобы определить места, где классы содержат слишком много зависимостей. Я не уверен, что это подсказка для кодирования. На этапе проектирования и не только там, когда вы решили использовать шаблон дизайна, просто подумайте о преимуществах. Я обнаружил, что Software Принципы проектирования чрезвычайно важны, чтобы помочь вам понять, когда и почему (а не) использовать шаблон дизайна, но они неизвестны многим программисты, которые используют шаблоны проектирования.
Я не уверен, что вы подразумеваете под Micro DP. Я пытаюсь использовать DP только тогда, когда я нахожу причины использовать их и когда преимущества кажутся больше, чем проблемы. Я избегаю чрезмерного использования, потому что это приводит к тому, что вы теряете время, реализуя и поддерживая шаблоны factory вместо реального программного обеспечения.

Ответ 2

Две хорошие книги, посвященные тому, как и когда (нет) использовать шаблоны проектирования:

Выведение штриховки (Джон Влиссидес из GoF)
Рефакторинг для шаблонов (Джошем Кериевским)

Ответ 3

Я думаю, что есть тенденция, по крайней мере, для тех, кто недавно изучает шаблоны дизайна, для чрезмерного применения шаблона; когда у вас есть молоток, все начинает выглядеть как гвоздь. Лучший способ сделать это - рассмотреть альтернативы API и их соответствующие преимущества и компромиссы, а затем выбрать то, что подходит. Шаблон проектирования - это скорее терминологическая помощь, которая позволяет разработчикам эффективно передавать то, что они делают, чем давать рекомендации о том, как писать код. То есть, некоторые вещи повторяются в коде, и проще сказать вашему коллеге, что вы использовали factory, чем объяснять, что у вас есть какой-то объект, который вы передали вокруг созданных других объектов... но только потому, что понятие фабрик существует не означает, что вы должны попытаться сделать все, что вы видите, в factory. Есть смысл?

Ответ 4

Шаблон проектирования описывает общее многоразовое решение для повторяющейся проблемы в данном контексте. Вы применяете шаблон, когда проблема (ы), связанная с личным дизайном, может решить шаблон. Это может произойти во время первоначального проектирования, во время кодирования, во время обслуживания и т.д. Абсолютного рецепта нет, IMO.

См. также

Ответ 5

1 и 2

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

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

3: Какие шаблоны, которые являются преобладающими, во многом зависят от домена. Государственные шаблоны, прокси-серверы и фасады очень распространены при работе с приложениями, которые обмениваются данными с другими системами. Приложение GUI имеет разные требования и т.д.

В моей отрасли (банковское дело): я вижу много следующих шаблонов GOF: Factory Метод, Singleton, Adapter и Facade. Поведенческие модели более или менее убиты преобладающими java-ee 14 слоями антипаттернов, которые были в режиме 10 лет назад.

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

5: Я думаю, что основной показатель для конкретной модели больше связан с проблемой и ее сходство с другими проблемами, которые были решены с помощью конкретной модели. Да, если код пахнет, это означает, что ему может потребоваться переписать, и проблема должна быть проанализирована снова. Хотя некоторые проблемы сложны и не могут быть уменьшены, большинство из них могут и шаблон могут помочь немного решить проблему.

Однако. Вследствие наблюдения, что сложные проблемы требуют сложных решений, толстые люди склонны писать сложный код; Что для этого. Например. Формы состояния (которые я люблю) могут усложнять вещи на невообразимые уровни, если они злоупотребляют.

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

Ответ 6

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

Рискуя заявить о явном модульном тестировании, уменьшает риск, но чем раньше вы это делаете, тем лучше. Я никогда не делал большого рефакторинга кода в поддержку внедрения нового шаблона, поскольку прилагаемые усилия редко показывали значительную выгоду. Если проект не собирается переходить в новую фазу развития.

Небольшие рефакторинги, содержащиеся в одном или двух методах, довольно распространены на протяжении всего жизненного цикла проекта, но они подпадают под предлогом отсутствия такой вещи, как "завершение кода":)

Ответ 7

ИМО, нет никаких правил или общих ситуаций. Шаблоны проектирования используются, когда они уместны, иногда вы знаете это при проектировании, иногда при кодировании, иногда при рефакторинге.

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

Ответ 8

Не забывайте книгу Design Patters, она может охватывать С++, но это не имеет значения, все шаблоны. Кроме того, книга очень хорошая.

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

Ответ 9

Я возьму здесь другой подход и не буду упоминать книги или адресовать все эти точки отдельно.

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

Как для подсказок, long methods = > refactor. Даже если он просто переходит к методам в одном классе, так как обычно этот промежуточный шаг показывает следующий ход.