Gdzie są wszystkie wzorce projektowania funkcjonalnego programowania? [Zamknięte]

Literatura programistyczna OO jest pełna wzorców projektowych. Większość książek o programowaniu obiektowym poświęca jeden lub dwa rozdziały projektowaniu wzorów, takich jak fabryki i dekoratorzy. Jakie są równoważne wzorce w językach funkcjonalnych i dlaczego nikt jeszcze nie napisał o nich książki? Czy jest coś specjalnego w językach funkcjonalnych, które eliminują potrzebę tworzenia wzorców projektowych?

OO i programowanie funkcjonalne to dwa bardzo różne paradygmaty programowania, a wzorce projektowe (DP) są istotną częścią projektowania i programowania OO. DP nie mają takiej roli w programowaniu funkcjonalnym.

Można nawet powiedzieć, że DP nie są potrzebne w programowaniu funkcjonalnym - nie ma swędzenia, na które DP jest lekarstwem.

• Można argumentować, że wzorce projektowe są oznaką brakujących cech w języku programowania.

• Peter Norvig stwierdził, że 16 z 23 wzorów w książce Design Patterns jest „ albo niewidocznych, albo prostych r” w Lisp lub Dylan.

• „Wiele wzorców implikuje orientację obiektową lub bardziej ogólnie stan zmienny, a zatem może nie być tak odpowiedni w funkcjonalnych językach programowania, w których dane są niezmienne lub traktowane jako takie.” - http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

Jeremy Gibbons pisze książkę. Do czasu jego ukończenia możesz przeczytać jego blog, Patterns in Functional Programming . Zaleca czytanie swoich postów od najstarszego do najnowszego.

Przeglądaj także jego publikacje . Omawia Gang of Four Patterns we wzorach projektowych jako programy generyczne dla wyższych typów danych i opisuje wzorce programowania za pomocą rekurencyjnych równań w Programowaniu Origami (fałdy i rozwinięcia).

Prostym faktem jest to, że wiele Wzorów OO byłoby uznawanych za Idiomy w językach funkcjonalnych (szczególnie oryginalne wzorce GoF). Na przykład wzorzec Iterator (teraz wbudowany w języki takie jak C #) po prostu nie jest konieczny w Lisp lub ML, który ma operatory sekwencji.

Wiele wzorców, których używamy w systemach OO, ma na celu pomóc nam usunąć „nieistotne” elementy, abyśmy mogli skupić się na kodowaniu obiektów. Innymi słowy, wzory są rozwiązaniami dla nieciekawych części aplikacji. Powinniśmy wykorzystywać wzorce, aby zaspokoić typowe potrzeby, które zostały wcześniej rozwiązane (takie jak wzorce w architekturze Fowlers Patterns of Enterprise Application Architecture do radzenia sobie z takimi rzeczami, jak transmisja bazy danych lub wzorce xUnit w celu usprawnienia testów jednostkowych), abyśmy mogli skupić się na zwiększaniu wartości biznesowej dla aplikacji.

Jestem pewien, że poza specyfiką wzorców GoF, istnieją wzorce projektowe, które będą miały zastosowanie również do programowania funkcjonalnego. Chodzi o to, że OO jest dominującym paradygmatem. Pisanie wzornika skierowanego do funkcjonalnych programistów ... cóż, szczerze mówiąc, nie dostanie zielonego światła od wydawcy. Do tego się sprowadza. Na rynku wzorów funkcjonalnych nie ma wystarczającej liczby książek poświęconych temu tematowi.

Dobra rozmowa (około 45 minut) na ten temat napisana przez Stuarta Sierra:

http://www.infoq.com/presentations/Clojure-Design-Patterns

Niekoniecznie wiążący i autorytatywny, ale rozpoznałem wiele jego przykładów z własnego doświadczenia z wykorzystaniem FP do analizy danych.

Przykłady napisane w Clojure, ale prawdopodobnie dotyczą dowolnego języka FP. Nazwy, które nadaje wzorom, które obejmuje, to:

• Stan / zdarzenie
• Konsekwencje
• Akumulator
• Zmniejsz / Połącz
• Rozbudowa rekurencyjna
• Rurociąg
• Obwoluta
• Znak
• Obserwator
• Strategia

Jeśli naprawdę interesuje Cię nauka wzorców projektowych, nie szukaj dalej niż Haskell. Jeśli poświęcisz trochę czasu na naukę języka w trudny sposób, na jaki natkniesz się i zaznajomisz z podstawowymi wzorami - są one upieczone w tym języku.

Nie pomijaj monad. Istnieje wiele długich i skomplikowanych wyjaśnień i potrzeba trochę pracy, aby pomysły zostały wprowadzone, ale jeśli nadal będziesz je podłączać, w końcu pojawi się na tobie i będziesz zaskoczony, jak wiele wzorów projektowych może być zbudowane na tej jednej abstrakcji / interfejsie.

Po zabiciu Haskella będziesz mieć do dyspozycji wystarczającą ilość arsenału FP, aby być niebezpiecznym. Chodzi o to, trzymaj się tego, dopóki go nie dostaniesz. Brak skrótów.

O ile metodologia projektowania dla FP polega na zaprojektowaniu typów dokładnie odzwierciedlających problematyczną przestrzeń, a implementacja powinna nastąpić automatycznie, odpowiednik FP książki na temat wzorców projektowych przypomina coś w rodzaju struktur funkcjonalnych danych Chrisa Okasakiego .