Насколько важны шаблоны проектирования в программировании?

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

Какова их цель и важны ли они для изучения?

Шаблоны проектирования отлично подходят для быстрой передачи ваших намерений - все знают, что такое Фабрика.

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

Из статьи в Википедии о шаблонах проектирования :

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

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

На самом деле существуют две разные существенные причины существования паттернов.

Первое уже объяснено довольно хорошо: использование шаблонов смазывает общение между разработчиками. Если вы и я оба понимаем, что когда я говорю «Наблюдатель», я говорю об очень специфической структуре кода, то я могу очень быстро описать, как работает фрагмент кода, использующий этот шаблон. Альтернативой является полное описание решения, которое занимает много времени и подвержено ошибкам. («Ну, я создал этот чистый виртуальный класс, который описывает и взаимодействует с объектами-потребителями, а затем я создал класс, который поддерживает список активных потребителей, который ...»)

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

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

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

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

Шаблоны о повторном использовании идей и концепций и об установлении общей / последовательной платформы для общения одного и того же.

Мы все согласны (!), Что теоретически повторное использование кода - это хорошо, но на практике это оказывается сложнее, чем нам бы хотелось (в некоторых отношениях это меняется, но это всегда будет проблемой ). Но на самом деле многое из того, что мы хотим использовать повторно, - это способ ведения дел, использование своего рода шаблона для построения решения конкретной проблемы - это паттерны. Таким образом, вы попадаете в случай, когда вы говорите, что хороший подход к решению проблемы X - это использовать шаблон Y, и мы знаем, что элементами шаблона Y являются a, b и c, и мы переходим. Поскольку шаблоны широко понятны, вам не нужно подробно объяснять, что является преимуществом коммуникации.

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

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

1. Они не зависят от языка. Как только вы узнаете, какой шаблон проектирования подходит для данной проблемы / архитектуры / задачи, вы можете реализовать его на любом языке с несколькими парадигмами - пусть это будет C #, Java или Python - решение в большинстве случаев будет таким же, вы просто адаптировать синтаксис. Это означает, что вы можете перенести свой опыт программирования на одном языке на другие языки, если вы остаетесь в одной проблемной области (и, возможно, даже в разных областях).

2. Несмотря на то, что шаблоны проектирования действительно связаны с парадигмой программирования , это означает, что шаблоны проектирования для объектно-ориентированного программирования (самые известные из них, также известные как шаблоны «Банды четырех» ). Шаблоны позволяют вам понять, для чего лучше всего подходит парадигма, и помочь вам выйти за рамки простого синтаксиса.Например, я видел много реализаций в C # и Java, где люди просто программировали так, как они это делали в Basic или Fortran - у них идеальный императив для решения проблем, и они используют ООП просто для рендеринга этого решения - без наследования нет полиморфизма, все методы общедоступны и т. д. Шаблоны проектирования помогают вам взглянуть на эти концепции и увидеть, как они работают в реальной жизни. То же самое относится к шаблону проектирования в других парадигмах, таких как функциональное программирование.

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

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

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

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

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

Джо Грегорио отлично рассказал об отсутствии шаблонов проектирования в Python.

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