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

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

Как сказано в принятом ответе, у ООП и ФП есть свои особые закономерности.

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

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

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

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

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

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