Odpowiednik zasad SOLID dla programowania funkcjonalnego

36

Uważam, że zasady SOLID są bardzo przydatne, gdy myślimy o projektowaniu obiektowym.

Czy istnieje podobny / równoważny zestaw zasad niezależnych od języka dostosowanych do programowania funkcjonalnego?

design-patterns functional-programming solid mikera
źródło
12
FWIW, zostało to krótko omówione na SO rok temu
StuartLC
DI i HOF: programmers.stackexchange.com/questions/103508/...
Paul
Ten film oraz slajdy przedstawiają zasady SOLID zastosowane do programowania funkcjonalnego. Obaj używają języka Clojure jako przykładu, ale zasady obowiązują w innych językach.
mascip
slideshare.net/RichardWarburton/…
Ray
patrz także: Czy programowanie funkcjonalne jest nadzbiorem obiektowym?
komar

Odpowiedzi:

14

Trochę trudno jest znaleźć odpowiedniki, ale mogę spróbować:

  • S (SRP) w FP funkcja tworzy ZAWSZE to samo wyjście dla tych samych argumentów, co nazywa się przezroczystością referencyjną
  • O (OCP) w FP istnieje koncepcja zwana algebraicznymi typami danych, spójrz, jak odnosi się do hierarchii klas i jaki problem oba próbują rozwiązać 1
  • L (LSP) Liskov Podstawową zasadą jest sprzeczność 2
  • D (DIP) w ogólnym programowaniu funkcjonalnym osiąga abstrakcję poprzez składanie funkcji, istnieją też inne mechanizmy za pomocą teorii kategorii (na przykład monoid lub funktor), dla „Wstrzykiwania zależności” 3
AndreasScheinert
źródło
21
Nadal myślę o tym, jak dostałeś się od zasady pojedynczej odpowiedzialności do przejrzystości referencyjnej . Te dwie rzeczy nie są ze sobą powiązane. SRP dotyczy funkcji mającej jeden cel. W związku z tym może, ale nie musi, być względnie przejrzysty.
Goran Jovic
3
Ach, moje złe - rozumiem już teraz. Są to odpowiedniki w tym sensie, że są zasadami i tworzą ten sam akronim, a nie w znaczeniu tego samego lub podobnego. Przepraszam za opinię!
Goran Jovic
1
Właśnie tak zamierzam to przeczytać. Próbowałem opisać mapowanie tych terminów w kontekście fp.
AndreasScheinert
Człowieku, nienawidzę tego, że nie możesz edytować komentarza, w rzeczywistości rzeczy POWINNY oznaczać przynajmniej coś podobnego.
AndreasScheinert
Może funkcje wyższego rzędu mogą zapewnić pewien rodzaj wstrzykiwania zależności: wstrzykujesz konkretną funkcję jako parametr do funkcji ogólnej (wyższego rzędu).
Giorgio,
45

SOLID okazuje się dobrym pomysłem także w królestwie funkcjonalnym / imperatywnym.

SRP - „Zrób tylko jedną rzecz” pochodzi przede wszystkim od programowania imperatywnego. Posiadanie małych, skoncentrowanych funkcji jest dobre.

OCP - Umożliwianie zmiany zachowań bez modyfikowania kodu jest dobre. Programowanie funkcjonalne wykorzystuje funkcje wyższego rzędu bardziej niż dziedziczenie, ale zasada obowiązuje.

LSP - Przestrzeganie niektórych umów interfejsu jest tak samo dobre w programowaniu funkcjonalnym, jak i obiektowym. Jeśli funkcja sortowania przyjmuje komparator, można oczekiwać, że „0 jest równe, mniej niż daje wyniki ujemne, większe niż wyniki dodatnie”.

ISP - Większość języków funkcjonalnych nadal ma struktury. Określanie najmniejszego zestawu danych wymaganych przez funkcję jest nadal dobrą praktyką. Wymaganie najmniej szczegółowego interfejsu do danych (dlaczego warto korzystać z list ints, gdy równie dobrze działają wyliczenia T?) Jest nadal dobrą praktyką.

DIP - Określanie parametrów funkcji (lub funkcji wyższego rzędu w celu ich odzyskania) zamiast twardego kodowania funkcji, aby uzyskać jakąś wartość, jest tak samo dobre w programowaniu funkcjonalnym, jak i obiektowym.

I nawet podczas programowania obiektowego wiele z tych zasad stosuje się również do projektowania metod w obiektach.

Telastyn
źródło