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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

Посмотрите, как 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".

Ответ 12

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

Ответ 13

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

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

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

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

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

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

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

Ответ 14

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

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

Ответ 15

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

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

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

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

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

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

Ответ 16

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

Ответ 17

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

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

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

Ответ 18

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

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

Ответ 19

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

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

Ответ 20

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

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

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

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

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

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

Ответ 21

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

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

Ответ 22

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

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

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

Ответ 23

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

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

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

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

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

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

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

Ответ 24

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