Функциональное программирование заменяет шаблоны дизайна GoF?

С тех пор как я начал изучать F # и OCaml в прошлом году, я прочитал огромное количество статей, которые настаивают на том, что шаблоны проектирования (особенно на Java) являются обходными решениями для недостающих функций на императивных языках. Одна статья, которую я нашел дает довольно сильные претензии:

Большинство людей, с которыми я встречался, прочитали Дизайн шаблонов книга от Ган 4. Любой уважающий себя программист скажут вам, что книга языковой агностик и шаблоны применительно к разработке программного обеспечения в вообще, независимо от того, какой язык ты используешь. Это благородное требование. К сожалению, он далек от правда.

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

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

Кроме того, в функциональных языках, поддерживающих OOP (например, F # и OCaml), мне кажется очевидным, что программисты, использующие эти языки, будут использовать те же шаблоны проектирования, которые доступны для всех других языков ООП. Фактически, прямо сейчас я использую F # и OCaml каждый день, и нет никаких ярких различий между шаблонами, которые я использую в этих языках, против шаблонов, которые я использую, когда пишу на Java.

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

863
29 нояб. '08 в 23:08
источник поделиться
23 ответов

Сообщение в блоге, которое вы цитируете, завышено. FP не устраняет необходимость в шаблонах проектирования. Термин "шаблоны проектирования" просто не используется широко, чтобы описывать одно и то же на языках FP. Но они существуют. Функциональные языки имеют множество правил лучшей практики в форме "когда вы сталкиваетесь с проблемой X, используйте код, который выглядит как Y", что в основном является шаблоном проектирования.

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

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

Вот что может сказать банда четырех из этой проблемы:

Выбор языка программирования важен, поскольку он влияет на одну точку зрения. Наши шаблоны предполагают особенности языка Smalltalk/С++, и этот выбор определяет, что может и не может быть легко реализовано. Если бы мы предполагали процедурные языки, мы могли бы включить шаблоны проектирования под названием "Наследование", "Инкапсуляция" и "Полиморфизм". Аналогично, некоторые из наших шаблонов поддерживаются непосредственно менее распространенными объектно-ориентированными языками. CLOS имеет несколько методов, например, которые уменьшают потребность в шаблоне, таком как Visitor. На самом деле, существует достаточно различий между Smalltalk и С++, что означает, что некоторые шаблоны могут быть легче выражены на одном языке, чем на другом. (См. Например, "Итератор" ).

(Вышеприведенная цитата из книги "Введение в дизайн шаблонов", стр. 4, параграф 3)

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

Что такое шаблон команды, если не аппроксимация первоклассных функций?:) На языке FP вы просто передаете функцию в качестве аргумента другой функции. На языке OOP вам необходимо завершить функцию в классе, который вы можете создать, а затем передать этот объект другой функции. Эффект один и тот же, но в ООП он называется шаблоном проектирования, и ему требуется намного больше кода. А что такое абстрактный шаблон factory, если не карри? Несколько раз передавайте параметры функции, чтобы настроить, какое значение она выплескивает, когда вы, наконец, назовете ее.

Итак, несколько шаблонов проектирования GoF оказываются избыточными на языках FP, потому что существуют более мощные и простые в использовании альтернативы.

Но, конечно, есть еще шаблоны проектирования, которые не решаются языками FP. Что такое эквивалент FP синглтона? (Не обращая внимания на то, что синглтоны, как правило, страшный шаблон для использования)

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

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

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

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

Кроме того, в функциональных языках которые поддерживают ООП (такие как F # и OCaml), мне кажется очевидным, что программисты, использующие эти языки будут использовать одни и те же шаблоны проектирования найденный для всех остальных ООП язык. Фактически, сейчас я использую F # и OCaml каждый день, и нет поразительные различия между шаблоны, которые я использую на этих языках vs шаблоны, которые я использую, когда пишу Java.

Возможно, потому, что вы все еще думаете императивно? Многие люди, когда они занимаются императивными языками всю свою жизнь, с трудом отказываются от этой привычки, когда они пробуют функциональный язык. (Я видел довольно забавные попытки в F #, где буквально каждая функция была просто строкой "let", в основном, как будто вы взяли программу на C, и заменили все точки с запятой "let".:))

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

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

Есть ли какая-либо истина в утверждении, что функциональное программирование устраняет потребность в шаблонах проектирования ООП?

Угу.:) Когда вы работаете на языке FP, вам больше не нужны шаблоны проектирования, основанные на ООП. Но вам по-прежнему нужны некоторые общие шаблоны проектирования, такие как MVC или другие не-ООП, и вам нужно несколько новых "шаблонов проектирования" для FP. Все языки имеют свои недостатки, а шаблоны проектирования обычно - это то, как мы обходим их.

В любом случае, вам может показаться интересным попробовать себя на "чистых" языках FP, таких как ML (мой личный фаворит, по крайней мере для учебных целей) или Haskell, где у вас нет костыля ООП, чтобы отступить когда вы столкнулись с чем-то новым.


Как и ожидалось, некоторые люди возражали против моего определения шаблонов проектирования как "исправления недостатков на языке", поэтому здесь мое оправдание: Как уже говорилось, большинство шаблонов проектирования специфичны для одной парадигмы программирования, а иногда и для одного конкретного языка. Часто они решают проблемы, которые существуют только в этой парадигме (см. Monads for FP, или абстрактные фабрики для ООП). Почему в FP нет абстрактного шаблона factory? Потому что проблема, которую он пытается решить, там не существует. Итак, если в языках ООП существует проблема, которая не существует на языках FP, то очевидно, что это недостаток языков ООП. Проблема может быть решена, но ваш язык этого не делает, но для вас требуется куча кода шаблона. В идеале мы хотим, чтобы наш язык программирования волшебно заставлял все проблемы уходить. Любая проблема, которая все еще существует, в принципе является недостатком языка.;)

878
30 нояб. '08 в 2:06
источник

Есть ли какая-либо правда в утверждении, что функциональное программирование устраняет необходимость в шаблонах проектирования ООП?

Функциональное программирование - это не то же самое, что объектно-ориентированное программирование. Объектно-ориентированные шаблоны проектирования не применяются к функциональному программированию. Вместо этого у вас есть шаблоны проектирования функционального программирования.

Для функционального программирования вы не будете читать книги шаблонов дизайна OO, вы прочтете другие книги по шаблонам проектирования FP.

языковой агностик

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

типичный шаблон проектирования ООП и его функциональный эквивалент?

Вышеупомянутое не должно существовать. Это как просить часть процедурного кода, переписанную как OO-код. Ummm... Если бы я перевел исходный Fortran (или C) на Java, я не сделал ничего больше, чем перевел его. Если я полностью переписал его в парадигму OO, она больше не будет выглядеть как оригинальный Fortran или C - она ​​будет неузнаваемой.

Нет простого сопоставления от OO Design до Functional Design. Они очень разные способы взглянуть на проблему.

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

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

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

125
29 нояб. '08 в 23:15
источник

Брайан комментирует тесную связь между языком и рисунком, чтобы точка,

Недопустимая часть этого обсуждения - это концепция идиомы. Книга Коплиена "Advanced С++" оказала огромное влияние. Задолго до того, как он обнаружил Кристофера Александра и Колонку Без имени (и вы не можете говорить разумно об узорах, не читая Александра), он говорил о важности овладения идиомой в истинном изучении языка. В качестве примера он использовал строчную копию в C, а (* from ++ = * - ++); Вы можете видеть это как бандад для недостающей языковой функции (или библиотечной функции), но что действительно имеет значение, так это то, что это большая единица мысли или выражения, чем любая ее часть.

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

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

36
01 янв. '09 в 23:59
источник

Книга GOF явно связывает себя с ООП - название - это шаблоны проектирования - элементы многоразового объектно-ориентированного программного обеспечения (выделение мое).

33
24 нояб. '09 в 18:49
источник

Design Patterns in Dynamic Programming от Peter Norvig задумчиво освещает эту общую тему, хотя об "динамических" языках вместо "функциональных" ( там перекрываются).

30
29 нояб. '08 в 23:23
источник

Здесь другая ссылка, обсуждающая эту тему: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

В своем блоге Edward описывает все 23 оригинальных шаблона GoF в терминах Haskell.

20
19 окт. '12 в 11:15
источник

Когда вы пытаетесь взглянуть на это на уровне "шаблонов проектирования" (в общем) и "FP против OOP", ответы, которые вы найдете, будут в лучшем случае мутными.

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

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

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

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

15
30 нояб. '08 в 2:15
источник

Презентация Norvig ссылается на анализ, который они сделали для всех шаблонов GoF, и говорят, что 16 из 23 шаблонов имели более простые реализации на функциональных языках или были просто частью языка. Поэтому предположительно по меньшей мере семь из них либо были одинаково сложными, либо б) не присутствовали на этом языке. К сожалению для нас, они не перечислены!

Я думаю, ясно, что большинство "творческих" или "структурных" шаблонов в GoF - всего лишь трюки, чтобы заставить примитивные системы типов на Java или С++ делать то, что вы хотите. Но остальные заслуживают внимания независимо от того, на каком языке вы программируете.

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

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

14
30 нояб. '08 в 10:11
источник

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

13
16 дек. '08 в 22:44
источник

И даже решения OO Design Pattern зависят от языка. Шаблоны проектирования - это решения общих проблем, которые ваш язык программирования не решает для вас. В Java шаблон Singleton решает проблему, связанную с чем-то (упрощенным). В Scala у вас есть конструкция верхнего уровня, называемая Object в дополнение к классу. Он лениво инстанцируется, и есть только один. Вам не нужно использовать шаблон Singleton для получения Singleton. Это часть языка.

8
30 нояб. '08 в 21:02
источник

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

7
26 авг. '13 в 5:10
источник

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

Посмотрите, как Scala устраняет "singleton pattern": вы просто объявляете объект вместо класса. Другая особенность, сопоставление шаблонов, помогает избежать неуклюжести шаблона посетителя. См. Сравнение здесь: http://andymaleh.blogspot.com/2008/04/scalas-pattern-matching-visitor-pattern.html

И Scala, как и F #, является слиянием OO-функционала. Я не знаю о F #, но у него, вероятно, есть такие возможности.

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

Еще одно наблюдение. Этот кусок кода реализует шаблон: он такой классический, и он настолько элементален, что мы обычно не думаем об этом как о "шаблоне", но он уверен:

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

Императивные языки, такие как Java и С#, приняли то, что по сути является функциональной конструкцией для решения этой проблемы: "foreach".

6
30 нояб. '08 в 0:43
источник

Шаблоны проектирования GoF - это кодирование обходных рецептов для языков OO, которые являются потомками Simula 67, например Java и С++.

Большинство "болезней", обработанных шаблонами проектирования, вызваны:

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

Ни один из этих шаблонов проектирования не исчезает в Common Lisp Object System, хотя решение структурировано по существу так же, как в соответствующем шаблоне проектирования. (Более того, эта объектная система предшествует книге GoF уже более десяти лет. Общий Lisp стал стандартом ANSI в том же году, когда эта книга была впервые опубликована.)

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

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

С другой стороны, поведенческие модели, такие как State и Strategy, вероятно, напрямую не применяются в функциональном ООП, поскольку в их основе лежит мутация государства. Это не означает, что они не применяются; возможно, они каким-то образом применяются в сочетании с любыми трюками, доступными для имитации изменчивого состояния.

6
09 дек. '13 в 20:45
источник

Я хотел бы подключить несколько отличных, но несколько плотных бумаг Джереми Гиббонса: "Модели дизайна как более высокоуровневые типы данных" и "Сущность шаблона итератора" (оба доступны здесь: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/).

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

6
17 сент. '10 в 3:30
источник

У вас не может быть этого обсуждения без создания систем типов.

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

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

Но, конечно, есть еще шаблоны проектирования, которые не решаются языками FP. Что такое эквивалент FP синглтона? (Не обращая внимания на то, что синглтоны, как правило, страшный шаблон для использования)

Первое, что делают стили, - это устранение необходимости в одиночных играх.

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

5
01 дек. '08 в 1:20
источник

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

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

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

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

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

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

3
29 июня '16 в 1:11
источник

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

3
01 окт. '12 в 13:51
источник

По существу, да!

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

Кроме того, эта страница (AreDesignPatternsMissingLanguageFeatures) предоставляет таблицу перевода "шаблон/функция" и некоторые приятные обсуждения, если вы готовы копать.

2
19 окт. '12 в 22:44
источник

В новой книге 2013 года под названием "Функциональные шаблоны программирования - в Scala и Clojure" автор Майкл Б.. Линн проводит достойную работу по сравнению и обеспечивает замену во многих случаях для шаблонов GoF, а также обсуждает новые функциональные шаблоны, такие как "хвостовая рекурсия", "memoization", "ленивая последовательность" и т.д.

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

2
20 мая '14 в 15:04
источник

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

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

2
01 дек. '08 в 1:00
источник

OOP и FP имеют разные цели, ООП стремится инкапсулировать сложности/движущиеся части программных компонентов, а FP направлена ​​на минимизацию сложности и зависимостей программных компонентов, однако эти 2 парадигмы не обязательно на 100% противоречат друг другу и могут применяться вместе получить выгоду от обоих миров. Даже с языком, который не поддерживает функциональное программирование, например, С#, вы можете написать функциональный код, если вы понимаете принципы FP, также вы можете применять принципы ООП с использованием F #, если вы понимаете принципы, шаблоны и лучшие практики ООП. Вы бы сделали правильный выбор в зависимости от ситуации и проблемы, которые вы пытаетесь решить, независимо от языка программирования, который вы используете.

1
13 дек. '16 в 13:57
источник

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

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

Я бы не использовал функциональный язык для написания пользовательского интерфейса, но один из языков OO, таких как С# или Java, облегчил бы эту работу. Если бы я писал функциональный язык, я бы не стал рассматривать шаблоны проектирования OO.

1
29 нояб. '08 в 23:18
источник

Как сказал принятый ответ, OOP и FP имеют свои специфические шаблоны.

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

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

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

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

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

  • Монад-трансформатор и декоратор. Первый использовал для добавления дополнительной способности в существующую монаду, последний добавляет дополнительную способность к существующему объекту.
0
12 июня '14 в 15:28
источник

Посмотрите другие вопросы по меткам или Задайте вопрос