Являются ли шаблоны проектирования вообще хорошей или плохой? [закрыто]

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

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

Итак, учитывая преимущества и проблемы, шаблоны проектирования обычно хорошие или плохие и почему?

31 голос | спросил Fishtoaster 4 +04002010-10-04T05:57:30+04:00312010bEurope/MoscowMon, 04 Oct 2010 05:57:30 +0400 2010, 05:57:30

11 ответов


49

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

  

Alex: Эй, как создаются файлы конфигурации?

     

Боб: Они созданы фабрикой, которая находится в config.h.

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

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

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

ответил P Shved 4 +04002010-10-04T09:32:13+04:00312010bEurope/MoscowMon, 04 Oct 2010 09:32:13 +0400 2010, 09:32:13
12

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

ответил ysolik 4 +04002010-10-04T06:18:41+04:00312010bEurope/MoscowMon, 04 Oct 2010 06:18:41 +0400 2010, 06:18:41
9

Конструктивные шаблоны великолепны, если их использовать правильно.

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

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

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

ответил George Marian 4 +04002010-10-04T11:57:56+04:00312010bEurope/MoscowMon, 04 Oct 2010 11:57:56 +0400 2010, 11:57:56
6

Я считаю, что дизайн шаблонов больше « совет », чем неотъемлемый контракт, который абсолютно необходимо соблюдать. Зачем? Именно по той причине, о которой вы говорили. Следуя шаблону проектирования во всем, он приводит к большому беспорядку кода, который побеждает цель использования шаблона в первую очередь.

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

TL; DR: Используйте шаблоны дизайна. Просто не злоупотребляйте ими.

ответил TheLQ 4 +04002010-10-04T06:40:15+04:00312010bEurope/MoscowMon, 04 Oct 2010 06:40:15 +0400 2010, 06:40:15
2

Также seet этот поток на SO. Из других шаблонов проектирования POV используется шаблонный код, чтобы компенсировать недостатки используемой методологии. Я не поклонник празднования этих обходных путей слишком много.

ответил LennyProgrammers 4 +04002010-10-04T12:14:09+04:00312010bEurope/MoscowMon, 04 Oct 2010 12:14:09 +0400 2010, 12:14:09
0

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

Понимание взаимосвязи шаблонов и видение шаблона в проекте (на стадии разработки) - вот что сделает вас хорошим разработчиком.

ответил 7 +04002010-10-07T13:51:56+04:00312010bEurope/MoscowThu, 07 Oct 2010 13:51:56 +0400 2010, 13:51:56
0

Часто говорят, что шаблоны проектирования предоставляют готовое решение для проблем программирования. Каковы проблемы? «Как изменить поведение объекта, но изолировать изменения от остальной системы?»

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

иерархия инкапсуляции шаблона проектирования

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

ответил Huperniketes 11 +04002010-10-11T20:50:30+04:00312010bEurope/MoscowMon, 11 Oct 2010 20:50:30 +0400 2010, 20:50:30
0

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

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

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

ответил cringe 15 +04002010-10-15T20:06:24+04:00312010bEurope/MoscowFri, 15 Oct 2010 20:06:24 +0400 2010, 20:06:24
0

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

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

ответил dsimcha 15 +04002010-10-15T20:16:05+04:00312010bEurope/MoscowFri, 15 Oct 2010 20:16:05 +0400 2010, 20:16:05
0

Оба лагеря правильны - они правильны, когда используются правильно, сила для плохих, если они разбрызгиваются повсюду.

ответил JohnL 15 +04002010-10-15T20:17:33+04:00312010bEurope/MoscowFri, 15 Oct 2010 20:17:33 +0400 2010, 20:17:33
0

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

ответил sunwukung 23 J000000Saturday11 2011, 02:17:03

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132