Odpowiednik zasad SOLID dla programowania funkcjonalnego

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

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:

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ć ¹
L (LSP) Liskov Podstawową zasadą jest sprzeczność ²
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” ³

— AndreasScheinert
źródło

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

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

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,

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