Шаблоны функционального, динамического и аспектно-ориентированного программирования

Ответ 1

Ранее задавался связанный вопрос: "Функциональное программирование заменяет шаблоны дизайна GoF" с отличными ответами.

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

Например, следующий код C

for (int i = 0; i < n; i++)
  if (a[i] == 42)
    return true;
return false;

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

Функциональное программирование имеет свои собственные методы, но они сильно отличаются от "шаблонов проектирования" в ООП. Они включают в себя использование полиморфизма, списки, функции более высокого порядка, неизменность/чистоту, лень [не все являются существенными или специфическими для FP]... См. Также "что такое основные понятия FP" . Кроме того, введите классы (Haskell), модули и функторы (OCaml), продолжения, monads, молнии, деревья пальцев, monoids, arrows, аппликативные функции, монадные трансформаторы, многие http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf "rel= "nofollow noreferrer" > чисто функциональные структуры данных (книга) и т.д. Функциональный жемчуг, о котором уже упоминал Рэндалл Шульц, является очень богатым ресурсом FP ​​в лучшем виде.

Чтобы узнать, как писать идиоматический код, любой книге/ресурсу на языке функционального программирования будет достаточно IMHO (например, RWH и LYAH); различия между мышлением императивно и функционально всегда объясняются там.

В динамических языках ссылка Джеффа Фостера - хорошая коллекция; здесь - очень умное использование memoization в JavaScript, которое можно рассматривать как "шаблон дизайна".

Ответ 2

Список шаблонов проектирования, описанных в GoF, написан для таких языков, как С++ и Java. Иногда это считается списком обходных решений, чтобы сделать гибкие языки более динамичными. Например, шаблон Visitor на самом деле не нужен в Ruby, потому что вы можете просто изменить функции-члены в свой класс во время выполнения. Шаблон Decorator устарел, если вы можете использовать mixins.

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

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

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

И теперь для чего-то другого. Если вам становится немного скучно с дизайном OO, и вы хотите узнать что-то новое, тогда вам может быть интересна книга Элементы программирования, написанная Stepanov. В этой книге он объясняет, как программирование можно подобрать с математической точки зрения. Для предварительного просмотра ознакомьтесь с его заметками класса для Adobe (среди прочих среди них эта страница). Вы также можете быть заинтересованы в Adobe Собранные документы.

Ответ 3

Здесь ссылка на Шаблоны проектирования в динамическом программировании

Ответ 4

Не являются ли функциональные жемчужины (одним из) канонического набора (-ов) шаблонов проектирования для функционального программирования?

Ответ 5

Существует Design patten в Ruby.

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

Ответ 6

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