it-swarm.com.ru

Заменяет ли функциональное программирование шаблоны проектирования GoF?

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

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

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

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

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

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

1013
Juliet

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

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

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

Вот что говорит Банда Четырех по этому вопросу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

1032
jalf

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

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

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

языковая независимость

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

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

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

Простого сопоставления между OO и ​​функциональным дизайном не существует. Они очень разные взгляды на проблему.

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

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

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

146
S.Lott

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

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

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

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

44
grahamsw

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

38
bright

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

33
Darius Bacon

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

В своем блоге Эдвард описывает все 23 оригинальных паттерна GoF с точки зрения Haskell.

25
folone

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

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

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

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

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

19
Brian

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

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

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

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

16
Neil Kandalgaonkar

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

15
Anders Rune Jensen

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

9
Dan Sickles

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

8
Edwin Buck

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

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

А Scala, как и F #, представляет собой сочетание ОО-функционала. Я не знаю о F #, но он, вероятно, имеет такие особенности.

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

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

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

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

8
Germán

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

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

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

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

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

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

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

8
Kaz

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

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

7
sclv

Вы не можете иметь это обсуждение, не поднимая системы типов.

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

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

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

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

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

6
Jason Ganetsky

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

4
CyaNnOrangeHead

По сути, да !

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

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

4
YvesgereY

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

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

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

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

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

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

3
oopexpert

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

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

2
Ali Bayat

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

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

2
manish

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

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

2
ktingle

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

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

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

1
Vincent Ramdhanie

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

1
Dogu Arslan

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

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

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

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

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

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

  • Монада трансформер и декоратор. Первый используется для добавления дополнительных способностей в существующую монаду, второй - для добавления дополнительных способностей к существующему объекту.
0
Earth Engine