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

Question

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

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

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

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

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

Answer 9

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

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

Answer 10

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

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