Когда шаблоны проектирования являются проблемой вместо решения?

Ответ 1

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

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

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

Ответ 2

Приходите, пожалуйста, прочитайте всю цитату, внимательно прочитайте ее. Или еще лучше, прочитайте эссе.

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

Логично использовать общие стратегии для решения повторяющихся проблем. В действительно абстрактных языках можно формализовать эти стратегии и поместить их в библиотеку. Всякий раз, когда вам нужно их использовать, вы просто # включаете их, создаете экземпляр, расширяете их или что-то еще. C-подобные языки в отличие не предоставляют необходимые средства абстракции. Об этом свидетельствует тот факт, что существует нечто вроде "шаблонов". Шаблон представляет собой такую ​​общую стратегию, которая не может быть выражена библиотечным кодом и поэтому должна быть выразительно написана каждый раз, когда она применяется.

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

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

Ответ 3

Шаблоны - это просто способ описания того, как все работает. Это способ их классификации. Существуют ли какие-то программы, которые их используют? Конечно. Самое большое преимущество наличия шаблонов состоит в том, что, классифицируя что-то как то или это, каждый находится на одной странице (при условии, что у них есть уровень знаний, чтобы знать, о чем говорят.). Когда у вас есть система с 10 000 строк кода, становится необходимым быстро определить, как что-то будет работать.

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

Ответ 4

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

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

Ответ 5

Форма программы должна отражать только проблема, которую он должен решить.

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

шаблоны проектирования являются признаком не достаточно абстракции

Скорее всего, если вы полностью отделили все, то у вас есть шаблон дизайна где-то там.

Что делать, если есть чрезвычайно "тяжелый" объект, который не нужно загружать? Шаблон прокси сохраняет пользователя в ожидании.

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

Ответ 6

Я считаю, что эта часть цитаты из Пола Грэма важна:

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

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

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

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

Ответ 7

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

Короткий ответ: если вы делаете настоящую работу на объектно-ориентированном языке, существует очень высокая вероятность того, что вы внедрили некоторые шаблоны дизайна GoF, чтобы выполнить эту работу. Знаете ли вы, что вы это сделали или нет, это вопрос образования, перспективы и самоанализа. Отрицать, что вы когда-либо делали те или иные шаблоны, не существуют или не являются "необходимыми" или "злоупотреблены", это смешно - если вы никогда не напишете ничего более сложного, чем "привет мир"; -)

Почему, просто на днях мне пришлось реализовать фасад посетителя для синглтона, чтобы заставить стратегию адаптера работать: -P

Ответ 8

Термин "Образцы дизайна" перегружен и запутан.

Существует узкий способ думать об этом: в основном как коллективное название концепций ОО, перечисленных в книге GoF, например, Singleton, Facade, Strategy. Вероятно, вы используете это определение, если вы поместите образцы дизайна в качестве компетенции на свое резюме.

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

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

Но концепция более общая - я думаю, что он искажает шаблоны проектирования. Кристофер Александр изобрел эту концепцию, чтобы применить ее к дизайну стран, городов, городов и домов. Разработчики игр имеют языки таких моделей, как Fog-of-War, Asymmetrical-Abilities и т.д.

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

Если вы не читали A Pattern Language, просмотрите область действия здесь. Представьте себе что-то подобное для мира программного обеспечения. Образцы GoF будут внизу в нижней части ToC: это детали реализации.

Какие еще шаблоны вы могли бы найти над ними?

Я думаю, что в одной главе были бы связанные с игрой шаблоны. Он может включать в себя как шаблоны дизайна игры, так и методы реализации, - и я утверждаю, что это не четкое различие, как, например, Game Loop, World Entity, пространственный хэш, ландшафт высоты карты и т.д. Это все шаблоны проектирования.

Теперь, в рамках одного игрового проекта, вы, вероятно, будете иметь только одну реализацию World Entity. Любой, кто работает на любом языке, имел бы смысл сделать этот объект World Entity реалистичной абстракцией, как базовый класс.

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

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

Платформа Erlang имеет реалистичные абстракции для шаблонов, как общие, как сервер, что здорово. И я предполагаю, что проект Erlang имеет столько серверов, сколько Java-проект имеет Singletons.

Но для ваших конкретных целей, если вы работаете в Lisp или Haskell или что-то еще, и записывая сервер, иногда достаточно просто следовать шаблону Server, реализуя его как старые добрые функции и объекты, без пытаясь сделать реальную абстракцию всего этого.

Все шаблоны проектирования не являются текстовыми шаблонами низкого уровня в исходном коде.

Ответ 9

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

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

На самом деле, вероятность того, что если вы запрограммировали что-либо разумного размера, вы использовали широко известные шаблоны дизайна и просто не знали, что есть имя для него. Например, я использовал шаблон "factory" в течение долгого времени, прежде чем я понял, что это "factory". Знание того, что он назвал официально, просто мешает мне снова изобретать колесо.

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

Но паттерны в целом - очень хорошая вещь, если что-то они поощряют абстракцию.

Ответ 10

Я считаю, что утверждение Пола Грэма состоит в том, что шаблоны дизайна должны быть выражены на языке. Если есть шаблон X, это означает, что люди вынуждены переписывать последовательности кода, чтобы сделать это, и должен быть язык, способный выразить его. Это может быть встроено в язык (хотя это неудобно и может создавать новые шаблоны проектирования), или он может быть автоматизирован в пределах языка (например, макросов Common Lisp; шаблоны С++, особенно когда они используются странными способами, могут многое сделать то же самое иногда).

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

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

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

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

Ответ 11

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

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

Если вы посмотрите на применение шаблонов прямо из смещения, не попадая в проблемную область, это может привести к проблемам. Используйте шаблоны проектирования в качестве руководства или более, так как подсказка/подсказка для решения проблемы. Сильно примененный шаблон дизайна, безусловно, не даст достаточно абстрактного решения. Часто видно, что в программном обеспечении Enterprise используется вариант или комбинация нескольких шаблонов проектирования... гибридов. Если вы говорите, что никогда не использовали шаблоны дизайна, вы были бы счастливы узнать, что что-то вроде цикла foreach на самом деле представляет собой шаблон взаимодействия, и вы можете охотиться за более очевидными реализациями рядом с вами!

Ответ 12

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

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

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

Ответ 13

Когда я запрограммировал в LISP, я вообще не использовал шаблоны дизайна GoF, он просто не применим для программ, которые я писал. Теперь я программирую на С# и выполняю все ситуации, когда шаблон проектирования фактически упрощает записываемую программу.

Ответ 14

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

Обобщение чего-то подобного будет логически ошибочным, но если вы перефразируете свой вопрос на что-то вроде "может ли быть слишком много шаблонов в коде, что является симптомом более серьезной проблемы, то есть недостаточных уровней абстракции" тогда ответ был бы "да". Это всегда так? Нет.

Ответ 15

Существует много максим, которые мы используем (и которые являются общими для SO), которые, если вы отследите их до источника, первоначально утверждались с резервированием; как в "... когда вы развиваете использование..." Это один из таких случаев. Образцы подходят хорошо, когда вы делаете ООП. YMMV, когда вы находитесь в другой парадигме.

"Рефакторинг" - еще один подобный случай.

Когда я пишу SQL, часть моего "шаблона" отключается.

Обратите внимание на свою цитату: "Я создаю вручную расширения какого-то макроса, который мне нужно написать". Поэтому он распознает шаблоны и абстрагирует их в макрос - он не перекодирует его по-другому. Просто хорошенький. Это не шаблоны, они не могут поступать правильно с теми, которые мы находим. Я бы сказал, что его комментарий может войти в любую запись в вики, расширяющуюся по достоинствам DRY, и как их владеть. GoF полностью согласен - распознает шаблоны desgin, а затем используйте то, что вы знаете о них, чтобы реализовать (или реорганизовать) их соответствующим образом.

Ответ 16

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

Часто, когда шаблоны проектирования применяются неправильно, это происходит потому, что процесс происходит в обратном порядке. Программист Джо (мои извинения для тех, кого вы назвали Джо) читает книгу о шаблонах дизайна и говорит: "Хорошо, я понимаю Design Pattern X, теперь как я могу применить его к моему приложению?" Это неправильно.

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

Ответ 17

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

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

Ответ 18

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

Шаблоны Diesign не представляют слишком маленькую абстракцию - они пытаются увеличить уровень абстракции. Вы можете сказать, что "этот бит - это посетитель", а не "вот какой-то код, который рекурсивно пересекает дерево объектов, выполняя операции над ними".

Ответ 19

Шаблоны - проблема, если они не являются решением. Под этим я подразумеваю: если шаблон вводится для шаблона, а не для решения реальной, существующей проблемы с дизайном в приложении, он может вызывать проблемы, а не решать или предотвращать их.
Я постоянно говорю людям на работе, что книга "Банда четырех" ( "Шаблоны дизайна: элементы многоразового объектно-ориентированного программного обеспечения" ) - это справочник, а не справочник для хорошего дизайна.

Ответ 20

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

Вот еще одна статья по теме: http://blog.plover.com/prog/design-patterns.html

Ответ 21

Я предпочел бы работать со слишком большим количеством шаблонов, чем вообще. Тем не менее, правильный баланс, конечно, является целью.

Ответ 22

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

Ответ 23

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

Ответ 24

Шаблоны проектирования - это решения для общих проблем.

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

Ответ 25

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

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

Итак, чтобы ответить на ваш вопрос, я бы сказал, что идея дизайна дизайна GoF неправильно понята и чрезмерно используется большинством. Нам нужно сориентироваться на более высокоуровневое использование шаблонов проектирования в качестве общего инструмента обучения, который применяется к тому, как мы изучаем и совершенствуем OO - не только как 20 идей куки-резака для запоминания и наложения на программы. Нет серебряной пули.

Ответ 26

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

Если вы предадите меня в метафоре: Написание музыки - это обычная "проблема", и музыка часто (явно не всегда) свободно складывается как какая-то вариация на следующее:

куплет хор стих хор стих хор хор

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

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