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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

термин "шаблоны проектирования" перегружен и запутан.

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

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

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

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

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

какие еще узоры вы могли бы найти над ними?

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

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

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

платформа Erlang имеет инстанцируемые абстракции для шаблонов, таких же общих, как сервер, что круто. И я думаю, что проект Erlang имеет столько же серверов, сколько проект Java имеет Синглеты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

стих припев стих припев стих припев припев

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

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