С тех пор, как я впервые узнал о шаблонах проектирования Gang of Four (GoF) , по крайней мере 10 лет назад, у меня сложилось впечатление, что эти 23 шаблона должны быть лишь небольшим образцом чего-то гораздо большего, что мне нравится называть Пространством шаблонов . Это гипотетическое пространство шаблонов состоит из всех рекомендуемых решений (известных или неизвестных) для общих проблем объектно-ориентированного проектирования программного обеспечения.
Поэтому я ожидал, что число известных и задокументированных шаблонов проектирования значительно возрастет.
Этого не случилось. Спустя более 20 лет после выхода книги GoF в статье Википедии перечислены только 12 дополнительных шаблонов, большинство из которых гораздо менее популярны, чем оригинальные. (Я не включил шаблоны параллелизма здесь, потому что они охватывают определенную тему.)
Каковы причины?
Является ли набор шаблонов GoF более полным, чем я думаю?
Упал ли интерес к поиску новых шаблонов, может быть потому, что они оказались не такими уж полезными в разработке программного обеспечения?
Что-то другое?
источник
Ответы:
Когда вышла Книга, многие подумали об этом, и было много попыток создать «библиотеки шаблонов» или даже «сообщества шаблонов». Вы все еще можете найти некоторые из них:
Но потом...
Это очень много. Смысл шаблонов проектирования заключается в улучшении связи между разработчиками, но если вы попытаетесь добавить больше шаблонов, вы быстро дойдете до того, что люди не смогут их запомнить, или запомнят их, или не согласятся, как именно они должны выглядеть, и коммуникация на самом деле не улучшилось. Это уже часто случается с паттернами GoF.
Лично я бы пошел еще дальше: дизайн программного обеспечения, особенно хороший дизайн программного обеспечения, слишком разнообразен, чтобы его можно было осмысленно отражать в шаблонах, особенно в небольшом количестве шаблонов, которые люди действительно могут запомнить - и они слишком абстрактны, чтобы люди действительно помню больше, чем горстка. Так что они мало помогают.
И слишком многие люди влюбляются в эту концепцию и пытаются применять шаблоны повсеместно - обычно в конечном коде вы не можете найти фактический дизайн между всеми (совершенно бессмысленными) синглетонами и абстрактными фабриками.
источник
ControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();
Это ужасное предположение, распространяемое программистами-неофитами повсеместно, программистами, которые думают, что могут написать программу, просто соединив программные шаблоны. Это не работает таким образом. Если существует такое «пространство образца», вы можете предположить, что его размер фактически бесконечен.
Шаблоны проектирования (в смысле GoF) преследуют только одну цель: компенсировать недостатки используемого вами языка программирования.
Шаблоны дизайна не являются ни универсальными, ни всеобъемлющими. Если вы переключитесь на другой, более выразительный язык программирования, большинство шаблонов в книге GoF станут ненужными и нежелательными.
источник
ObservableSomething<T>
что облегчает понимание их назначения, поскольку использует общеизвестное имя шаблона. Шаблон - это идея, а не точная реализация.Я думаю, что здесь есть три фактора.
Недостаток критической массы
Во-первых, шаблон - это немного больше, чем присвоение имени некоторому коду, который реализует определенный «кусок» функциональности. Единственный способ, которым имя обеспечивает большую реальную ценность, - это если вы можете зависеть от того, что все знают, что означает это имя, поэтому, просто используя имя, они сразу же многое поймут о коде.
Образцы никогда не устанавливали критическую массу, в которой они нуждались, чтобы достигнуть этого все же. Скорее наоборот, AAMOF. За 20 (или около того) лет, с тех пор как вышла книга GoF, я почти уверен, что не видел столько дюжин разговоров, в которых каждый вовлеченный действительно знал достаточно шаблонов дизайна для их использования для улучшения коммуникации.
Короче говоря, шаблоны проектирования потерпели неудачу именно потому, что они потерпели неудачу.
Слишком много паттернов
Я думаю, что вторым важным фактором является то, что, во всяком случае, они изначально назвали слишком много шаблонов. В большинстве случаев различия между шаблонами являются достаточно тонкими, поэтому практически невозможно точно сказать, соответствует ли тот или иной класс тому или иному шаблону (или, возможно, обоим - или, возможно, ни одному).
Предполагалось, что вы сможете говорить о коде на более высоком уровне. Вы сможете пометить довольно большой кусок кода как реализацию определенного шаблона. Просто используя это заранее определенное имя, все слушатели, как правило, знают столько, сколько заботятся об этом коде, чтобы вы могли перейти к следующему.
Реальность имеет тенденцию быть почти противоположным. Допустим, вы находитесь на собрании и скажите им, что этот конкретный класс является Фасадом. Половина людей на собрании либо никогда не знали, либо давно забыли, что именно это означает. Один из них просит вас напомнить ему о точной разнице (ях) между Фасадом и, скажем, Прокси. Да, и пара людей, которые действительно знают шаблоны, проводят оставшуюся часть собрания, обсуждая, действительно ли это следует считать Фасадом или «просто» Адаптером (при этом один парень все еще настаивал на том, что для него это похоже на Прокси).
Учитывая, что ваше намерение было просто сказать: «этот код не очень интересен; давайте двигаться дальше», пытаясь использовать имя шаблона только для отвлечения внимания, а не значения.
Отсутствие интереса
Большинство шаблонов проектирования на самом деле не имеют дело с интересными частями кода. Они имеют дело с такими вещами, как: «как мне создать эти объекты?» И «как мне заставить этот объект общаться с этим?» Запоминание названий шаблонов для них (а также вышеупомянутых аргументов в отношении деталей и тому подобного) просто придает много энергии вещам, о которых большинство программистов просто не заботятся.
Говоря немного по-другому: шаблоны имеют дело с тем же, что и во многих программах, но что действительно делает программу интересной, так это то, как она отличается от других программ.
Резюме
Разработка шаблонов не удалась, потому что:
источник
В шаблонах отсутствуют абстракции, простые шаблоны абстрагированы, сложные шаблоны не распознаются, поэтому шаблоны бесполезны (за исключением нескольких высокоуровневых).
Я думаю, что Пол Грэм сказал это лучше всего:
Когда вы узнаете шаблон в своем коде, это означает, что что-то повторяется, и вам следует использовать лучшую абстракцию. Если у вас нет лучшей абстракции, вы можете использовать шаблон в качестве обходного пути. Поскольку новые языки программирования обеспечивают лучшие абстракции, шаблоны становятся гораздо менее полезными.
Также простые шаблоны часто легко абстрагируются, а сложные шаблоны редко распознаются.
Когда шаблон заменяется абстракцией, это не означает, что концепция, лежащая в основе шаблона, исчезает, но концепция может быть написана явно, а не косвенно, и что она больше не является особенной по сравнению с другим кодом, и она больше не распознается как шаблон.
источник
String.replace
функции, вы можете представить ее как шаблон, но лучше написать ее один раз, а не продолжать переопределять ее. Согласитесь, что если вы не называете эти вещи должным образом, это затруднит чтение, но когда все сделано правильно, код будет более декларативно считывать IMO (например,getOrElse
стиль монад опций против проверки на нуль)Хотя я в основном согласен с тем, что здесь ответили другие, я лично считаю, что главная причина не растущего числа шаблонов состоит в том, что шаблоны теряют свое значение, когда их существует бесчисленное множество. Хорошая вещь с этими несколькими шаблонами состоит в том, что они покрывают множество проблемных областей стандартным способом. Если бы вы сосредоточились на бесконечной области шаблонов, вы бы вообще не получили шаблонов. Это немного похоже на «какова длина береговой линии острова?». Если вы измеряете на карте, вы получите приличное число. Но если вы попытаетесь получить более точное и более точное разрешение, вы обнаружите, что длина увеличивается все больше и больше до бесконечности (или неопределенности; как бы вы измерили точную границу с приливами и на атомном уровне?).
источник
То, что не упоминается ни в одном из других ответов, также имеет отношение к делу:
Рост динамически типизированных языков.
Когда книга вышла в свет, возникла серьезная дискуссия о том, что Java слишком медленна, чтобы выполнять настоящую работу. Теперь Java часто используется в более выразительных языках из- за своей скорости. Возможно, Ruby, Python, JavaScript и др. Все еще слишком медленны для некоторых важных классов приложений, но в целом они достаточно быстры для большинства целей. И JavaScript, по крайней мере, на самом деле становится быстрее, несмотря на то, что в каждом выпуске упаковано больше функций.
Оригинальная книга GoF имела шаблоны как на smalltalk, так и на c ++, и, если память обслуживает, шаблоны всегда были короче на smalltalk, а иногда и значительно. Некоторые функции классических шаблонов проектирования - это действительно способы добавления динамических функций в статически типизированную систему (например, уже обсуждаемая AbstractFactory, в которой вы создаете правильный класс на основе данных времени выполнения). Другие настолько короче в динамических языках, что просто смешиваются с идиоматическим использованием самого языка.
источник
Это же произошло. Были опубликованы десятки, если не сотни книг, что выглядело как попытка свести всю компьютерную науку к разработке шаблонов, поскольку издатели и авторы пытались запрыгнуть (или создать) еще одну популярность. У меня есть полка из них. Никогда не консультировался с тех пор, как впервые отсканировал, и да, я был отстой, потому что там было мало или вообще ничего реального использования или это не было уже хорошо известно (см., Например, Type Object, который является не чем иным, как третьей нормальной формой, выраженной над дюжина страниц вместо одного абзаца), и потому, что, очевидно, чем меньше шаблонов, тем лучше: точка, которая ускользает от большинства практикующих. Действительно, когда я опубликовал опровержение Type Object, мне было поручено преобразовать мой текст в шаблон дизайна.Правдивая история. Что также указывает на еще один недостаток проекта: отсутствие механизма обзора, исключения или отказа.
На самом деле GoF на самом деле не пытался «тщательно изучить шаблоны проектирования». Скорее, они были вовлечены в гораздо более крупный проект: внедрить «язык шаблонов» в CS со всеми его причудливыми обозначениями Сил, Участников и т. Д., Которые просто потерпели неудачу, потому что это было в корне неверно, а также бессмысленно.
То, что они сделали , что было полезно, это две вещи:
Другой полезной концепцией, которая возникла, был «анти-паттерн», например, «бери и бросай». Проект, как и многие увлечения в CS, был сорван из-за его собственной евангелизации и из-за того, что он был ошибочно принят как еще одна религия CS, и он пошел по пути большинства таких религий: полезен по частям, но, конечно, «без серебряной пули» ((c Фред Брукс, 1965). Грустно, что мы должны снова и снова открывать это каждые несколько лет.
источник
Было / есть несколько книг под названием PLoP ( Шаблонные языки разработки программ ), каждая из которых представляет собой сборник статей, представленных на ежегодной конференции .
Читая книги, я обнаружил, что некоторые шаблоны были интересными и новыми для меня, некоторые из них были стандартами (например, «половина объекта плюс протокол»).
Так что нет, коллекция GoF не была исчерпывающей и вдохновляла / вдохновляла людей собирать / описывать / открывать / изобретать новые.
«Только 12 дополнительных шаблонов, перечисленных в статье в Википедии», по-видимому, также не являются полной коллекцией: то есть есть другие, документированные в другом месте, например, в книгах по PLoP и, возможно, в другом месте.
источник
Книга Gang of Four (GoF) содержит большинство шаблонов, которые опытный программист на не функциональном языке имеет в своем поясе инструментов. Это как базовый набор инструментов, который все строители знают, как использовать. Основной вклад книги состоял в том, чтобы дать четко определенное название шаблонам, которые в то время широко использовались большинством опытных программистов, и, следовательно, помогать коммуникации между программистами, обсуждающими варианты дизайна.
Вы ожидаете, что у электрика есть некоторые инструменты, которых нет у обычного компоновщика, также вы ожидаете, что программист WPF будет знать шаблоны проектирования для «Свойства зависимости», или «Программист SQL» знает шаблон проектирования для использования триггеров для создать данные аудита.
Однако мы не думаем о них как о «шаблонах проектирования», поскольку они используются только с одной технологией.
Еще несколько книг по шаблонам проектирования модемов «Рефакторинг, улучшение дизайна существующего кода (Мартин Фаулер)» и «Чистый код: руководство по гибкому программному обеспечению (Роберт К. Мартин) ». Обе эти книги представляют содержимое в виде преобразований, которые вы делаете к вашему текущему коду, а не как «готовый дизайн многократного использования», однако они являются такими же «шаблонами дизайна».
источник
Вот интервью с Эрихом Гаммой, где он размышляет об их выборе моделей и о том, что они изменят сегодня (ну, сегодня, 10 лет назад, ха-ха).
http://www.informit.com/articles/article.aspx?p=1404056
источник
Фактические шаблоны в книге иногда очень полезны, но на самом деле они являются просто примерами более мощного инструмента, который дает вам книга: глубокое понимание того, когда и где лучше разрезать монолитный код на независимые части, разделенные и регулируемые интерфейсом. ,
Когда вы изучаете этот навык, вы понимаете, что вам не нужно запоминать точные детали каждого шаблона, так как вы всегда можете обрезать решение, которое вы реализуете, в соответствии с его назначением. Так что идея записывать все новые и новые шаблоны кажется очень академичной и бессмысленной.
источник
Книга GoF и Википедия - едва ли единственный источник известных шаблонов дизайна. Если вы просто ищете «шаблоны проектирования» на Amazon.com, вы получите сотни книг (попробуйте этот поиск ). Я предполагаю, что они только перечисляют самый известный образец в статье Wikipedia .
Таким образом, проблема не в том, что недостаточно документированных шаблонов проектирования. Скорее всего, их так много, что никто не может запомнить их все, и большинство программистов узнают лишь немногих. Большое обещание общего языка шаблонов рушится на этом этапе.
источник
Вероятно, есть множество структур, о которых еще не думали. Пока люди разрабатывают программное обеспечение, будут проблемы с дизайном, которые необходимо преодолеть. Некоторые из них вполне могут быть решены с использованием новых хитроумных шаблонов, которые могут использовать другие.
Языки программирования развивались и развивались, чтобы абстрагироваться от наиболее часто используемых шаблонов. Эти шаблоны все еще существуют в дизайне языков. Так что сегодня их можно игнорировать, но это не делает их неважными.
Является ли знание того, как построить дом, внезапно неважным, когда у нас есть роботы, которые могут сделать это для нас? Я бы сказал, нет, это не так. Конечно, это менее актуально - и, вероятно, намного менее полезно для учебы, поскольку спрос резко упал, и никто больше его не изучает.
Так что нет, я не верю, что шаблонное пространство, как вы его называете, исчерпано. Как указал другой ответ, он, вероятно, будет бесконечным. Но по мере того, как спрос на системное проектирование уменьшается, поскольку мы увеличиваем высоту нашей башни абстракции и мощь наших языков программирования - все меньше и меньше людей, строящих на верхних уровнях, будут обращать внимание на детали того, как была построена башня ,
источник
Шаблоны бесконечны. Вы можете настроить каждый шаблон или смешать n совпадений, чтобы создать новые. Шаблоны корпоративной интеграции также хорошо определены ... так что да, gof очень старался документировать шаблоны с использованием uml и создал стандарт для их объяснения. Но для каждого домена шаблоны развиваются, и они также изменяются для выразительного языка, такого как python или scala ..
источник