Шаблоны для функционального, динамического и аспектно-ориентированного программирования
Попробуйте Неблокировщик .
сайт Неблокировщика имеет изящную диаграмму (прокрутите вниз после того, чтобы переходить по ссылке), который показывает сравнение с другими инструментами. Очевидно, такие сравнения обычно смещаются, так как они обычно пишутся автором инструмента, но диаграмма, по крайней мере, перечисляет альтернативы так, чтобы можно было судить их за себя.
6 ответов
A related question was asked before: "Does functional programming replace GoF design patterns", with great responses.
The equivalent of "design patterns" is very vague in FP. In general, every time you see a "pattern" in your code you should create something to cover all of its uses in a uniform way. Often it will be a higher-order function.
For example, the following C code
for (int i = 0; i < n; i++)
if (a[i] == 42)
return true;
return false;
can be thought of some basic "design pattern" - checking if there's some special element on the list. This snippet could appear many times in code with different conditions. In FP, you simply use a higher order function several times. It's not a "pattern" anymore.
Functional programming has its own practices, but they are much different from "design patterns" in OOP. They include use of polymorphism, lists, higher-order functions, immutability/purity, laziness [not all are essential or specific to FP]... See also "what are core concepts of FP". Also, type classes (Haskell), modules and functors (OCaml), continuations, monads, zippers, finger trees, monoids, arrows, applicative functors, monad transformers, many purely functional data structures (book) etc. Functional pearls, already mentioned by Randall Schulz, form a very rich resource of FP at its best.
To learn how to write idiomatic code, any book/resource on a functional programming language will suffice IMHO (for example, RWH and LYAH); differences between thinking imperatively and functionally are always explained there.
In dynamic languages, Jeff Foster's link is a good collection; here is a very clever use of memoization in JavaScript that could be considered a "design pattern".
Вот ссылка на Шаблоны проектирования в динамическом программировании
Помимо шаблонов проектирования, упомянутых в GOF, в нем также перечислены некоторые другие шаблоны, такие как Соглашение по конфигурации .
Разве функциональные жемчужины (один из) канонических наборов шаблонов проектирования для функциональных программирование?
Список шаблонов проектирования, описанный в GoF, написан для таких языков, как C ++ и Java. Иногда его считают списком обходных путей, позволяющих сделать негибкие языки более динамичными. Например, шаблон Visitor на самом деле не нужен в Ruby, потому что вы можете просто изменить добавление функций-членов в свой класс во время выполнения. Шаблон Decorator устарел, если вы можете использовать миксины.
По моему опыту, когда я реализую решение на C ++, я, как правило, трачу большую часть своего времени на написание кода скаффолдинга. Я начинаю с создания платформы, которая позволяет мне мыслить в программной области моего приложения. Шаблоны проектирования, вероятно, были разработаны как способ категоризации различных видов каркасов.
Я должен упомянуть, что когда я программирую на Ruby, у меня мало поддерживающего кода. Просто нет Кажется, в этом есть необходимость.
Моя теория состоит в том, что другие языки не подчеркивают концепцию шаблонов проектирования просто потому, что их базовых языковых конструкций достаточно. В защиту Java и C ++: возможно, это связано с тем, что функциональные языки и языки АОП часто используются в более конкретных проблемных областях или нишах, в то время как Java и C ++ используются для всего.
А теперь о другом. Если вам немного наскучил объектно-ориентированный дизайн и вы хотите узнать что-то новое, то вам может быть интересна книга Элементы программирования , написанная Степановым . В этой книге он объясняет, как можно подойти к программированию с математической точки зрения. Для предварительного просмотра ознакомьтесь с его Примечаниями к классу для Adobe (среди прочих можно найти на этой странице ).
Personally my most important pattern for dynamic languages - write tests. It's even more important than in statically-typed languages.