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

Question

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

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

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

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

Answer 1

Две хорошие книги, которые имеют дело с как и , когда (не) использовать шаблоны проектирования:* (Джон Влиссидес из GoF)

Рефакторинг к паттернам (Джош Кериевский)

Answer 2

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

2. Да, как уже упоминалосьдо.

3. в 99,99% случаев: Factory Pattern , Singleton (Как и все, я использую его во многих местах, потому чтореализовать, и на практике я склонен удалить его при рефакторинге кода).Затем: Пул объектов (если у меня есть ресурсы, которые я хочу использовать повторно - некоторые из моих проектов - игры, и мне нужно хорошее управление ресурсами), Стратегия и метод шаблонов (потому что они отлично подходят для разделения и хорошо служатцель сделать код легко расширяемым).Тогда Adapter - это то, что нужно использовать, когда у вас есть библиотека, которую вы хотите использовать, не полагаясь на нее (развязывание).

4. То же, что и выше, если я еще не использовал их.Это работает и в обратном направлении.Если я не нахожу причину использовать шаблон проектирования, я удаляю его или пропускаю при написании кода (это происходит постоянно с синглтоном и время от времени с фабриками. Иногда я использую фабрику, которая также являетсяпредоставьте мне те, которые должны были быть объектами синглетонов; не уверен, что это разумно, но это работает для меня).

5. Единственная подсказка кода, я думаю, это числоссылки у вас на класс.Вы также можете использовать PMD , jDepend и Правила архитектуры , чтобы определить места, где классы содержат слишком много зависимостей.Я не уверен, что это совет по кодированию.На этапе проектирования, а не только там, когда вы решите использовать шаблон проектирования, просто подумайте о преимуществах.Я обнаружил, что Software Принципы проектирования чрезвычайно важны, чтобы помочь вам понять, когда и почему (не) использовать шаблон проектирования, но они неизвестны многим программистам, использующим шаблоны проектирования .

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

Answer 3

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

Answer 4

1 & 2

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

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

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

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

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

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

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

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

Answer 5

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

См. Также

• Написание программных шаблонов
• Узоры в двух словах

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

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