Когда звонить в банду из четырех человек? [Когда использовать шаблоны дизайна?] - PullRequest
13 голосов
/ 04 ноября 2008

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

Мне трудно определить, следует ли применять шаблон проектирования, предложенный Бандой четырех .

Поэтому мне хотелось бы привести несколько примеров из Вашего опыта работы

  • Когда достаточно простого подхода (массив фиксированного размера)?
  • Каков минимальный размер программного обеспечения, оправдывающего использование шаблонов GoF?
  • Когда рефакторинг от простого к GoF? Можно ли это сделать разумным способом?

Ответы [ 7 ]

18 голосов
/ 06 ноября 2008

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

  • Когда простой подход достаточно? всегда достаточно использовать самый простой подход, чтобы получить следующий тест, чтобы пройти. Но зная когда / как рефакторинг это настоящее искусство форма.
  • Каков минимальный размер часть программного обеспечения, которая оправдывает использование шаблонов GoF? Правило большой палец, я когда-то читал, что когда ты закодируйте что-нибудь один раз, хорошо, когда вы дублировать этот код где-то во второй раз запишите и переместите на. Когда вы обнаружите необходимость в тот же код в третий раз, пришло время рефакторинг для удаления дублирования и упростить, и часто это включает в себя переходя к шаблону дизайна.
  • Когда рефакторинг от простого к GoF? Мне нравится то, что сказал @anopres - это время, когда вы чувствуете боль не имея шаблон дизайна на месте. Боль (или код «запах») может проявлять себя несколькими способами. Дублирование кода является наиболее очевидно. Рефакторинг таких книг, как Фаулера Рефакторинг или Реакция Кериевского на Образцы перечисляют много таких болей точки / код вони.
  • Может это [рефакторинг] должно быть сделано в разумном способ? Хитрость к рефакторингу заключается в иметь набор модульных тестов на месте в котором вы уверены, и затем провести рефакторинг, не вызывая каких-либо из этих тестов провалиться. Рефакторинг по определению не изменить функциональность вашего код. Поэтому, если ваши тесты продолжать проходить, вы можете иметь довольно хорошее чувство, что ты не сделал сломать что-нибудь. Хотя это может быть сложно, но на самом деле мне нравится эта часть TDD, это почти как игра, в которой можно вносить изменения, не нарушая никаких тестов.

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

11 голосов
/ 06 ноября 2008

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

Только на следующий день на собрании команды вы экономите каждые тридцать минут скуки, говоря: «Я использовал шаблон стратегии. Все они работают одинаково, поэтому есть только одна тестовая программа, для изменения которой требуется параметры».

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


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

10 голосов
/ 07 ноября 2008

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

В любом случае вы не просто «переключаетесь» на «использование шаблона». Ты просто продолжаешь делать то, что всегда делаешь, пишешь код так, как ты умеешь.

7 голосов
/ 04 ноября 2008

Это похоже на любое другое дизайнерское решение. В конечном счете, это зависит. Вы должны изучить те шаблоны, которые полезны на вашем языке (например, многие шаблоны GoF не нужны в Lisp или Smalltalk), изучить их преимущества и недостатки, понять ограничения вашей системы и сделать выбор, который лучше всего соответствует вашим потребностям .

Лучший совет, который я могу дать, - учиться, учиться, учиться.

3 голосов
/ 06 ноября 2008

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

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

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

2 голосов
/ 06 ноября 2008

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

0 голосов
/ 10 ноября 2008

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

Еще одно хорошее место, с которого можно начать - это Head First Design Patterns. Упражнения, которые иллюстрируют использование различных шаблонов проектирования, достаточно сложны, чтобы предложить хороший опыт обучения. Кроме того, упражнения также основаны на сценариях реального мира, поэтому никогда не бывает трудно определить подходящее время для применения шаблонов проектирования.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...