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


19

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

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


7
Их хорошо знать для собеседования!
Вим

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

7
Понимание цели шаблонов проектирования требует понимания проблем, которые они решают. Понимание этих проблем требует опыта, чтобы сделать это трудным путем :)
MattDavey

Ответы:


36

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

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


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

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

1
Каждый код содержит некоторый шаблон, даже если вы не знаете об этом. Шаблоны проектирования, о которых вы говорите, просто перегруппируются и назовите набор широко используемых и полезных шаблонов. Когда вы их знаете, вы можете думать о них более осознанно. Если вы называете один из ваших классов «ControlDispenser», вероятно, никто не будет знать, что он должен делать. Однако, если вы знаете фабричный шаблон, вы назовете его «ControlFactory», и другие сразу поймут.
Оливье Жако-Дескомб

4
Если это служит другой цели, это должен быть другой класс ... разделение интересов.
конец

2
@Nate: одной целью может быть несколько шаблонов. Нет причины, по которой один класс должен включать только один шаблон. Шаблоны не являются «атомными» обязанностями. Для одной ответственности может потребоваться несколько схем.
DeadMG

26

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

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

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


3
Сравнение разработки программного обеспечения с электротехникой примерно так же точно, как сравнение ракеты Сатурн с велосипедом. Оба способа транспортировки (добраться из пункта А в пункт Б), но идут по нему совершенно по-разному и несовместимы.
Джер

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

6
@ Mike: есть это принципиальное отличие: электрические схемы ограничены жесткие физические ограничения. Программные системы ограничены нечеткими пределами человеческого интеллекта.
Кевин Клайн

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

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

9

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

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

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

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

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

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


2
Это ошибочное мнение, что шаблоны проектирования являются готовым решением. Они «УЗОРЫ», это не всегда переводится в код.
Мартин Йорк,

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

5

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

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

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


4

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

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

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

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

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


2

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


1

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


1

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

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


Спасибо за ссылку об отсутствии шаблонов проектирования в Python. Редактировать: Ой! Видео было удалено из этого места! :(
Саураб Патил

0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.