Zaraz rozpocznę projekt symulacji / modelowania. Wiem już, że OOP służy do tego rodzaju projektów. Jednak badanie Haskella skłoniło mnie do rozważenia zastosowania paradygmatu FP do modelowania układu komponentów. Pozwól mi rozwinąć:
Załóżmy, że mam komponent typu A, charakteryzujący się zestawem danych (parametr taki jak temperatura lub ciśnienie, PDE i niektóre warunki brzegowe itp.) Oraz komponent typu B, charakteryzujący się innym zestawem danych (różnym lub ten sam parametr, różne PDE i warunki brzegowe). Załóżmy również, że funkcje / metody, które zostaną zastosowane do każdego komponentu, są takie same (na przykład metoda Galerkina). Zmienny stan obiektu zostałby zastosowany do parametrów niestałych.
Gdybym miał zastosować podejście OOP, stworzyłbym dwa obiekty, które enkapsulowałyby dane każdego typu, metody rozwiązywania PDE (dziedziczenie byłoby tu użyte do ponownego użycia kodu) i rozwiązanie PDE.
Z drugiej strony, gdybym miał zastosować podejście FP, każdy komponent byłby podzielony na części danych i funkcje, które działałyby na dane w celu uzyskania rozwiązania dla PDE. Parametry niestałe byłyby przekazywane jako funkcje czegoś innego (na przykład czas) lub wyrażane przez pewnego rodzaju zmienność (emulacja zmienności itp.) To podejście wydaje mi się prostsze, zakładając, że liniowe operacje na danych byłyby trywialne.
Podsumowując, czy wdrożenie podejścia FP byłoby faktycznie prostsze i łatwiejsze w zarządzaniu (dodaj inny typ komponentu lub nową metodę rozwiązania pde) w porównaniu do OOP?
Pochodzę z środowisk C ++ / Fortran, a ponadto nie jestem profesjonalnym programistą, więc popraw mnie na wszystko, co popełniłem źle.
źródło
IMHO na prawie każde zadanie o rozsądnej złożoności nie można obiektywnie odpowiedzieć na pytanie „styl FP lub styl OOP lepszy wybór”. Zazwyczaj w takiej sytuacji pytaniem nie jest „ani FP, ani OOP”, ale jak połączyć najlepsze części obu paradygmatów w celu rozwiązania problemu.
Problem, który naszkicowałeś powyżej, wydaje się bardzo matematyczny, i przypuszczam, że będziesz potrzebować kilku operacji na macierzach. OOP jest bardzo dobry do modelowania abstrakcyjnych typów danych, a rachunek macierzowy można łatwo zaimplementować jako „obiekty macierzy” za pomocą operacji na macierzach. Zaimplementowanie tego w sposób, w którym wszystkie operacje na macierzach są częścią klasy macierzy, pomaga utrzymać razem rzeczy, które do siebie należą, dzięki czemu zachowana jest dobra ogólna struktura.
Z drugiej strony, PDE są równaniami funkcji, a rozwiązaniem może być znowu funkcja. Zatem zastosowanie funkcjonalnego podejścia do tego rodzaju „komponentów” może wydawać się tutaj naturalne. Funkcje te mogą mieć parametry macierzy, pokazujące jeden przykład połączenia OOP i FP. Innym przykładem może być implementacja klasy macierzy, która wykorzystuje narzędzia funkcjonalne do mapowania określonej operacji na każdy element macierzy. Także tutaj nie jest to „OOP kontra FP”, ale „OOP w połączeniu z FP”, który przynosi najlepsze wyniki.
źródło