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

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

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

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

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

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

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

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

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

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

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

Шаблоны дизайна хороши, если используются правильно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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