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

13

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

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

«Банда четырех» - это такой стандарт для ОО-программистов, но есть ли что-то подобное, более ориентированное на функциональную парадигму? У большинства ресурсов, которые я нашел, есть отличные слепки программирования, но они не отступают, чтобы дать более широкий, более архитектурный вид.

Андрей
источник
6
Некоторые из шаблонов GOF - это просто обходные пути в ОО-языках для вещей, которые уже есть в функциональном программировании. См. Stackoverflow.com/q/327955
Роберт Харви
2
связанные: stackoverflow.com/q/89212
буксиры
Я думаю, что в этом обсуждении слишком много внимания уделяется шаблонам, специфичным для GoF / OOP. Может ли кто-нибудь опубликовать некоторые фактические шаблоны, специфичные для функционального программирования (которые не просто пытаются доказать тривиальность GoF на функциональных языках)?
Даниэль Б

Ответы:

3

Подобные паттерны обычно являются признаками сломанной, непригодной базовой модели.

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

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

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

SK-логика
источник
+1 за последние 2 абзаца, я думаю, что это место. Что касается ООП, мне любопытно обосновать, почему он назван неработоспособным, за исключением того факта, что это универсальный инструмент, часто применяемый для решения конкретных проблем (отсюда и возникают низкоуровневые паттерны, такие как GoF). Можете ли вы уточнить вкратце или опубликовать ссылку, обобщающую ваше мнение?
Даниэль Б
@DanielB, нет ничего плохого в ООП как таковом, но способ, которым он обычно применяется, полностью нарушен. Эта модель подходит только для некоторых реальных проблем (и она действительно сияет, когда применяется соответствующим образом), но в остальном ей нужны все эти костыли и клейкая лента, чтобы соответствовать. Смотрите мой ответ на programmers.stackexchange.com/questions/52608/... , например.
SK-logic
ОК, я думаю, что я на той же странице. На самом деле, я, возможно, задал этот точный вопрос однажды, извините за это - то, как вы сформулировали эту строку, кажется, что вы подразумеваете больше.
Даниэль Б
-3

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

Однако, если бы я применил свой исходный код к более широкой среде разработки и сказал кому-то, что есть проблема с этим определенным методом ... для этого разработчика было бы трудно отследить проблему. ОДНАКО, если бы я сказал, что Контрактный Контроллер был испорчен по какой-то причине, он (а) точно знал бы, с чего начать.

Шаблоны дизайна великолепны ... но, как я уже сказал, я думаю, что они семантические!

РЕДАКТИРОВАТЬ: Вы типа евангелиста взломать меня. Как что-либо могло быть разработано без MVC (или какого-либо другого шаблона проектирования)!

aserwin
источник
2
семантическая (sɪˈmæntɪk) - прил. 1 или относящаяся к значению или возникающая из различий между значениями различных слов или символов 2. или относящаяся к семантике (изучение значения) 3. логика, связанная с интерпретацией формальной теории, как, когда таблицы истинности даны как отчет о связных предложениях
Роберт Харви
+1 - моя точка зрения заключалась в том, что шаблоны проектирования - это просто средство общения!
Aserwin
Шаблоны проектирования - это больше, чем просто способ общения; это конкретные, понятные рецепты, которые могут быть реализованы в программном обеспечении для решения определенных, часто встречающихся проблем.
Роберт Харви
Это то, что говорится в книгах. Но на самом деле я никогда не решал проблему с помощью шаблона проектирования, который я не мог бы решить без него. Единственное преимущество, которое я заметил на собственном опыте, - это возможность говорить друг с другом о коде! ;)
Aserwin
1
Относительно вашего редактирования: То есть вы бы предпочли заново изобретать колесо каждый раз, когда пишете новый фрагмент кода?
Роберт Харви