Банда Четырех тщательно исследовала «Пространство Образца»?

144

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

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

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

Каковы причины?

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

design-patterns object-oriented-design

— Фрэнк Пуффер
источник

49

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

— USR

6

Дизайн пространства? Кто-нибудь, приведите сюда Марка Розуотера, стат!

— CorsiKa

16

Мартин Фаулер опубликовал « Шаблоны архитектуры корпоративных приложений» в 2003 году, в котором документировано около 50 шаблонов, многие из которых до сих пор достаточно реконфигурируемы и широко используются, например «Data Mapper», «Plugin», «Lazy Load», «Service Layer» и т. Д.

— Брайан Роджерс

2

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

— Надеюсь, что это

4

@BradThomas: Конечно, как и в большинстве интересных вопросов, люди склонны иметь определенное мнение. Но мнения, по крайней мере, частично основаны на фактах, и я нашел много интересных фактов в ответах на этот вопрос, которые помогут мне и, надеюсь, другим переосмыслить свои мнения и прийти к более обоснованным.

— Фрэнк Пуффер

165

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

"Шаблон сообщества" , WikiWikiWeb
"Исследовательская группа шаблонов дизайна Нью-Йорка" , Индустриальная логика
"Каталог шаблонов" , Группа Хиллсайд

Но потом...

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

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

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

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

— Майкл Боргвардт
источник

50

Спорные мнение: Абстрактная фабрика код запах все равно :)

— MetaFight

66

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

— Дэвид Арно

18

@MetaFightControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();

— corsiKa

11

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

— верьте

11

@ChrisW Я не понимаю твоей точки зрения ... Как я уже сказал, GoF пытался преодолеть недостатки OO, и особенно недостатки C ++ 98, так как это был их предпочтительный язык наряду с Smalltalk. Они на самом деле написали: «Выбор языка программирования важен, потому что он влияет на точку зрения. Наши шаблоны предполагают особенности языка уровня Smalltalk / C ++, и этот выбор определяет, что можно, а что нельзя легко реализовать».

— Shautieh

108

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

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

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

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

— Роберт Харви
источник

40

«Шаблоны проектирования (в смысле GoF) имеют только одну цель: компенсировать недостатки в используемом вами языке программирования». Я продолжаю слышать это, но до сих пор не вижу оправданного. Каждое предполагаемое обоснование этого просто указывает на несколько шаблонов, которые легче реализовать на языках с какой-либо функцией - обычно Visitor и, возможно, Singleton - и оставляет без изменений подавляющее большинство шаблонов, просто подразумевая, что их тоже можно сделать избыточными лучшие языки. Но как мы узнаем? Какая языковая особенность делает Observer нерелевантным? Цепочка ответственности? Композитный?

— Жюль

56

@Jules Только функции первого класса устраняют значительную их часть, включая Chain of Responsibility (это просто составление списка функций). Функционально-реактивное программирование устраняет шаблон Observer. Шаблон Composite - это менее строго определенное определение моноидов, а языки с классами типов и акцентом на алгебраические законы дают мощные инструменты для работы с моноидами. Я мог бы перечислить еще много, но вы поняли идею.

— Джек,

12

@Jules: Я полагаю, что в оригинальной книге GoF итератор был указан в качестве шаблона, но теперь его преобразование в языковую функцию в основном завершено на каждом языке ООП.

— Кевин

9

@RubberDuck, как уже реализованный шаблон делает шаблон устаревшим? Это все еще реализуемая модель проектирования. Различные наборы языковых функций могут привести к различным реализациям шаблона, но сам шаблон все еще там. Шаблоны призваны облегчить общение, дав имена повторяющимся стратегиям, которые обычно используются. В данном случае вызываются классы .NET, ObservableSomething<T>что облегчает понимание их назначения, поскольку использует общеизвестное имя шаблона. Шаблон - это идея, а не точная реализация.

— ноль

29

@Jules: Что такое программа? Решение повторяющейся проблемы. Что такое шаблон дизайна? Решение повторяющейся проблемы. Почему это не программа? Потому что мы не можем выразить это как программу. Следовательно, Шаблон проектирования - это решение повторяющейся проблемы, которая должна быть Программой, а не Шаблоной проектирования, но не может быть Программой, поскольку язык недостаточно выразителен для выражения Программы. Пример: не так давно «Вызов подпрограммы» был шаблоном дизайна! В наше время это особенность языка.

— Йорг W Mittag

61

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

Недостаток критической массы

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

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

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

Слишком много паттернов

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

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

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

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

Отсутствие интереса

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

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

Резюме

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

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

— Джерри Гроб
источник

2

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

— Триларион,

5

Очень хороший ответ

— Роберт Харви

4

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

— Джерри Гроб

3

@DavidRicherby: Хорошо, тогда давайте воспользуемся «аналогичной» версией аналогии. Имеет ли значение, что Джон, который разрабатывает шины для Goodyear, использует одно слово для этого типа канавки, а Пьер, который работает на Мишлен, использует совершенно другое слово? Имеет ли значение, что один использует слово, относящееся только к канавке, а другой - слово, относящееся к полной шине с горизонтальными канавками на одной стороне от центра и диагональными канавками на другой?

— Джерри Гроб

2

@immibis: Я бы сказал, в основном, да, они потерпели неудачу. Я бы сказал, что большинство программистов распознают менее полудюжины шаблонов. Синглтон хорошо известен, но на самом деле он применяется редко (в лучшем случае). Название «Фабрика» была в общем пользовании задолго до того, «узоры» пришел (я помню его использование в конце 1970 - х или очень начале 1980 - х). Шаблоны должны были сформировать словарь, но в настоящее время они похожи на мой словарь по-гречески - достаточно, чтобы (возможно) попасть в неприятности, но, конечно, недостаточно, чтобы упорядочить меню, а тем более провести содержательный разговор.

— Джерри Гроб

35

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

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

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

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

— Siphor
источник

2

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

— Фрэнк Пуффер

2

@ Фрэнк Я думаю, откуда приходит PG, это то, что паттерн - это «запах» базовой функции, которую вы можете абстрагировать, а тот факт, что вы не вытащили его в функцию или макрос, является причиной повторения - например, если у вас нет String.replaceфункции, вы можете представить ее как шаблон, но лучше написать ее один раз, а не продолжать переопределять ее. Согласитесь, что если вы не называете эти вещи должным образом, это затруднит чтение, но когда все сделано правильно, код будет более декларативно считывать IMO (например, getOrElseстиль монад опций против проверки на нуль)

— другой день

11

Цитата Пола Грэма заключалась в том, чтобы сохранить ваши решения СУХИМЫМИ, что отличается от идеи «шаблона» GoF. Идея GoF заключалась в том, чтобы дать имена часто используемым решениям. Мы уже делали это задолго до того, как GoF опубликовал их книгу. Например, я могу сказать своему коллеге, что собираюсь использовать очередь , и мой коллега сразу знает, о чем я говорю, без необходимости объяснять детали того, что делает очередь или как она работает. Но, см. Превосходный ответ Майкла Боргвардта, выше.

— Соломон Медленный

10

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

— Малкольм

3

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

— Барт ван Ниероп,

13

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

— qwerty_so
источник

1

Правильно, шаблоны могут работать, только если их не слишком много. Но почему GoF по-прежнему самые популярные? Некоторые из них в настоящее время рассматриваются как антипаттерны многими людьми (Синглтон, Строитель и т. Д.). Это должно освободить место для новых, более полезных шаблонов без увеличения общего количества.

— Фрэнк Пуффер

2

Я думаю, что это как 10 заповедей. Источник всего в 2-х символах (GOF, GOE, GOD) xD

— qwerty_so

9

Да, и иногда кажется, что современная разработка программного обеспечения относится к GoF, как средневековая схоластика относится к Аристотелю.

— Фрэнк Пуффер

11

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

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

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

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

— Джаред Смит
источник

10

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

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

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

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

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

— user207421
источник

Это все еще печально , если это привело к этой дискуссии (и все , что влечет за собой)

— r3wt

1

@ r3wt Non sequitur. То, что я сказал, печально, так это то, что ИТ-индустрия слаба за то, что думает, что каждая новая разработка будет мифической серебряной пулей, и, между прочим, за то, что она испортила некоторые из своих предыдущих работ.

— user207421

2

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

— r3wt

6

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

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

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

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

— ChrisW
источник

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

— Фрэнк Пуффер

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

— ChrisW

1

@FrankPuffer Бьюсь об заклад, шаблоны популярны, даже если названия нет.

— августа

5

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

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

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

Еще несколько книг по шаблонам проектирования модемов «Рефакторинг, улучшение дизайна существующего кода (Мартин Фаулер)» и «Чистый код: руководство по гибкому программному обеспечению (Роберт К. Мартин) ». Обе эти книги представляют содержимое в виде преобразований, которые вы делаете к вашему текущему коду, а не как «готовый дизайн многократного использования», однако они являются такими же «шаблонами дизайна».

— Ян
источник

3

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

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

Ларри: Как бы вы изменили «Дизайн шаблонов»?

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

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

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

Интерпретатор и Flyweight должны быть перемещены в отдельную категорию, которую мы назвали «Other / Compound», так как они действительно разные звери, чем другие модели. Фабричный метод будет обобщен на Фабричный.

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

Новые члены: Null Object, Type Object, Dependency Injection и Extension Object / Interface (см. «Объект расширения» в Языках шаблонов разработки программы 3, Addison-Wesley, 1997).

Это были категории:

Ядро: составное, стратегия, состояние, команда, итератор, прокси, шаблонный метод, фасад

Создание: Фабрика, Прототип, Строитель, Внедрение Зависимостей

Периферийные: абстрактная фабрика, посетитель, декоратор, посредник, тип объекта, нулевой объект, объект расширения

Другое: Flyweight, Переводчик

— akuhn
источник

Почему ты меня опускаешь? Пожалуйста, объясните в комментарии, чтобы я мог улучшить ответ.

— Акун

3

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

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

— lud1977
источник

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

— Фрэнк

@ lud1977 Если мы не записываем историю, что мешает будущему попасть в те же ловушки? таким образом, это всегда должно быть записано. это не бессмысленно.

— r3wt

2

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

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

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

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

— iluwatar
источник

-1

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

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

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

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

— Тим
источник

-2

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

— Марут Сингх
источник