Разве «Банда четырех» тщательно исследовала «Паттерн-космос»?

С тех пор, как я впервые узнал о шаблонах дизайна банды четырех (GoF) , по крайней мере 10 лет назад у меня создалось впечатление, что эти 23 шаблона должны быть только небольшим образцом чего-то гораздо большего, что мне нравится называть Pattern Space . Это гипотетическое Pattern Space состоит из всех рекомендуемых решений (известных или неизвестных) для общих проблем проектирования объектно-ориентированного программного обеспечения.

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

Этого не произошло. Спустя 20 лет после выхода книги GoF в статью Википедии перечислены только 12 дополнительных шаблонов, большинство из которых гораздо менее популярны, чем оригинальные. (Я не включил здесь шаблоны параллелизма, потому что они охватывают конкретную тему.)

В чем причины?

  • Является ли набор шаблонов GoF более полным, чем я думаю?

  • Разве интерес к поиску новых шаблонов падал, может быть, потому, что они оказались не такими полезными в разработке программного обеспечения?

  • Что-то еще?

140 голосов | спросил Frank Puffer 12 62016vEurope/Moscow11bEurope/MoscowSat, 12 Nov 2016 18:31:17 +0300 2016, 18:31:17

14 ответов


160

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

Но тогда ...

  

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

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

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

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

ответил Michael Borgwardt 12 62016vEurope/Moscow11bEurope/MoscowSat, 12 Nov 2016 18:48:29 +0300 2016, 18:48:29
103
  

У меня сложилось впечатление, что эти 23 шаблона должны быть только небольшим образцом чего-то гораздо большего, что мне нравится называть Pattern Space.

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

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

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

ответил Robert Harvey 12 62016vEurope/Moscow11bEurope/MoscowSat, 12 Nov 2016 19:07:57 +0300 2016, 19:07:57
57

Я думаю, что здесь есть три фактора.

Отсутствие критической массы

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

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

Немного более странно: шаблоны проектирования не удались, потому что они не удались.

Слишком много шаблонов

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

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

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

Учитывая, что ваше намерение состояло в том, чтобы просто сказать: «этот код не очень интересен, давайте двигаться дальше», пытаясь использовать имя шаблона только добавленное отвлечение, а не значение.

Недостаток интереса

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

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

Резюме

Не удалось создать шаблоны проектирования, потому что:

  1. Им не удалось достичь критической массы.
  2. Дифференциация между шаблонами была недостаточной для обеспечения ясности.
  3. В основном они касались частей кода, о которых практически никто не заботился.
ответил Jerry Coffin 14 12016vEurope/Moscow11bEurope/MoscowMon, 14 Nov 2016 09:00:49 +0300 2016, 09:00:49
34

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

Я думаю, что Пол Грэм сказал это лучше всего:

  

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

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

ответил Siphor 13 72016vEurope/Moscow11bEurope/MoscowSun, 13 Nov 2016 03:09:15 +0300 2016, 03:09:15
13

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

ответил Thomas Kilian 12 62016vEurope/Moscow11bEurope/MoscowSat, 12 Nov 2016 22:18:26 +0300 2016, 22:18:26
11

Что-то, о чем не упоминается ни один из других ответов, также имеет значение:

Появление динамически типизированных языков.

Когда вначале вышла книга, было серьезное обсуждение того, что Java слишком медленна для реальной работы. Теперь Java часто используется для более выразительных языков , потому что его скорости. Возможно, Ruby, Python, JavaScript и др. Все еще слишком медленны для некоторых важных классов приложений, но по большому счету они достаточно быстры для большинства целей. И JavaScript, по крайней мере, на самом деле ускоряется, несмотря на то, что в каждом выпуске есть больше функций.

В оригинальной книге GoF были шаблоны как в smalltalk, так и в c ++, и если память обслуживает шаблоны, они всегда были короче в smalltalk, а иногда и значительно. Некоторые из особенностей классических шаблонов дизайна - это действительно способы добавления динамических функций в статически типизированную систему (например, уже обсуждавшийся AbstractFactory, в котором вы создаете правильный класс на основе данных времени исполнения). Другие настолько короче в динамических языках, что они просто объединяются в идиоматическое использование самого языка.

ответил Jared Smith 14 12016vEurope/Moscow11bEurope/MoscowMon, 14 Nov 2016 21:03:35 +0300 2016, 21:03:35
8

Он сделал . Десятки, если не сотни книг, были опубликованы в том, что было похоже на попытку сократить всю компьютерную науку до разработки шаблонов, поскольку издатели и авторы попытались перейти (или создать) еще одну подножку. У меня есть полка. Никогда не проконсультировался с момента первого сканирования, и да, я был присосками, потому что там было мало или вообще ничего не было, или что еще не было хорошо известно (см., Например, Type Object, который является не более чем третьей нормальной формой, выраженной над десяток страниц вместо одного абзаца), и потому, что, очевидно, чем меньше шаблонов, тем лучше: точка, которая ускользает от большинства практиков. В самом деле, когда я опубликовал опровержение Type Object, мне было поручено переделать текст в качестве шаблона проектирования. Истинная история. Что также показывает еще один недостаток проекта: нет механизма обзора или исключения или отказа.

На самом деле GoF фактически не пытался «тщательно изучить шаблоны проектирования». Скорее, они занимались гораздо более масштабным проектом: ввести «шаблонный язык» в CS со всей своей причудливой звуковой арканой Сил, участников и т. Д., Которые просто провалились, потому что это было принципиально неверно понято, а также было бессмысленным.

Что они сделали , что было полезно, было две вещи:

  • опубликуйте несколько полезных трюков, таких как шаблон посетителя
  • предоставить стандартный набор имен, который в значительной степени застрял: Factory, Adapter, Iterator, ... Если вы посмотрите на CORBA, который был разработан сразу же, вы увидите значение этого: всевозможные «чужие» имена таких как Interceptor, Servant, Broker, ...

Еще одна полезная концепция, которая возникла, - это «анти-шаблон», например. «log and throw». Проект, как и многие причуды в CS, был сорван его собственной евангелизацией и ошибочно принят как еще одна религия CS, и он пошел по пути большинства таких религий: полезен по частям, но, безусловно, «нет серебряной пули» ((c ) Фред Брукс, 1965). Грустно, что мы должны заново открывать это каждые несколько лет.

ответил user207421 16 32016vEurope/Moscow11bEurope/MoscowWed, 16 Nov 2016 14:13:33 +0300 2016, 14:13:33
5

Были /есть несколько книг под названием PLoP ( языки шаблонов дизайна программы ), каждая из которых является антологией докладов, представленных на ежегодной конференции .

Читая книги, я обнаружил, что некоторые из шаблонов были интересны и новы для меня, некоторые из них - стандарты (например, «half object plus protocol»).

Нет, коллекция GoF не была исчерпывающей и вдохновляла /вдохновляла людей собирать /описывать /открывать /изобретать новые.

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

ответил ChrisW 13 72016vEurope/Moscow11bEurope/MoscowSun, 13 Nov 2016 03:19:06 +0300 2016, 03:19:06
4

Книга «Банда четырех» (GoF) содержит большинство моделей, которые опытный программист не имеет в функциональном языке в своем поясе. Это похоже на базовый набор инструментов, которые все строители знают, как использовать. Основной вклад книги состоял в том, чтобы дать четко определенное имя шаблонам, которые в то время были наиболее распространены большинством опытных программистов , и, следовательно, помогать коммуникации между программистами, обсуждающими варианты дизайна.

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

Однако мы не думаем об этом как о «шаблонах дизайна», потому что они используются только с одной технологией.

Некоторые более современные шаблоны шаблонов дизайна «Реформирование, улучшение дизайна существующего кода» (Martin Фаулер) â € и âClean Код: Руководство по гибкому программному мастерству (Robert C. Martin) â € Обе эти книги представляют содержимое как преобразования, которые вы делаете в свой текущий код, а не как «готовые многоразовые проекты», однако они представляют собой так же «условные образцы».

ответил Ian 14 12016vEurope/Moscow11bEurope/MoscowMon, 14 Nov 2016 19:07:15 +0300 2016, 19:07:15
2

Вот интервью с Эрихом Гамма, где он размышляет о выборе образцов и о том, что они изменили сегодня (ну сегодня, по состоянию на 10 лет назад, ха-ха).

http://www.informit.com/articles/article.aspx ? р = 1404056

  

Ларри: Как бы вы реорганизовали «шаблоны проектирования»?

     

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

     

Когда мы обсуждаем, какие паттерны падать, мы обнаружили, что мы все еще любим их всех. (Не совсем. Я за то, что выбрал Синглтон. Его использование почти всегда является дизайнерским запахом.)

     

Итак, вот некоторые из изменений:

     
  • Переводчик и мухи должны быть переведены в отдельную категорию, которую мы называем «Другое /Соединение», поскольку они действительно разные звери, чем другие модели. Заводский метод будет обобщен на Factory.
  •   
  • Категории: Core, Creational, Peripheral и прочее. Цель здесь состоит в том, чтобы подчеркнуть важные шаблоны и отделить их от менее часто используемых.
  •   
  • Новые члены: Null Object, Type Object, Injection Dependency и Extension Object /Interface (см. «Расширяемый объект» в языках шаблонов программирования 3, Addison-Wesley, 1997).
  •   
  • Это были категории:      
    • Ядро: композитный, стратегический, государственный, командный, итератор, прокси, шаблонный метод, фасад
    •   
    • Creational: Factory, Prototype, Builder, Injection Dependency
    •   
    • Периферийное оборудование: абстрактный завод, посетитель, декоратор, медиатор, объект типа, нулевой объект, объект расширения
    •   
    • Прочее: мухи, переводчики
    •   
  •   
ответил akuhn 22 ThuEurope/Moscow2016-12-22T23:28:09+03:00Europe/Moscow12bEurope/MoscowThu, 22 Dec 2016 23:28:09 +0300 2016, 23:28:09
2

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

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

ответил lud1977 26 Jpm1000000pmThu, 26 Jan 2017 12:04:28 +030017 2017, 12:04:28
1
  

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

     

Этого не произошло. Спустя более 20 лет после выхода книги GoF,   только 12 дополнительных шаблонов перечислены в статье Википедии, большинство   из которых гораздо менее популярны, чем оригинальные. (Я не   здесь используются шаблоны параллелизма, поскольку они охватывают конкретные   тема.)

Книга GoF и Википедия вряд ли являются единственным источником известных шаблонов дизайна. Если вы просто ищете «шаблоны дизайна» на Amazon.com, вы получаете сотни книг (попробуйте это поиск ). Я предполагаю, что они перечисляют наиболее известный шаблон в статье Википедии .

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

ответил iluwatar 15 22016vEurope/Moscow11bEurope/MoscowTue, 15 Nov 2016 23:32:51 +0300 2016, 23:32:51
-1

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

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

Является ли знание о том, как построить дом, внезапно несущественный, когда у нас есть роботы, которые могут это сделать для нас? Я бы сказал, нет, это не так. Это менее актуально, конечно - и, вероятно, гораздо менее полезно учиться, так как спрос резко падает, и никто не изучает его.

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

ответил Tim 16 32016vEurope/Moscow11bEurope/MoscowWed, 16 Nov 2016 07:51:45 +0300 2016, 07:51:45
-2

Шаблоны бесконечны. Вы можете настроить каждый шаблон или сочетание n для создания новых. Шаблоны интеграции предприятия также хорошо определены. Так что gof действительно страдает от документирования шаблонов с использованием uml и создал стандарт для объяснения их .. Но для каждой модели домена развиваются, и они также меняются для выразительного языка, такого как python или scala ..

ответил Marut Singh 12 62016vEurope/Moscow11bEurope/MoscowSat, 12 Nov 2016 20:24:54 +0300 2016, 20:24:54

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

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

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