Programowanie funkcjonalne a programowanie obiektowe [zamknięte]

Do tej pory byłem głównie narażony na programowanie OO i nie mogę się doczekać nauki funkcjonalnego języka. Moje pytania to:

• Kiedy wybierasz programowanie funkcjonalne zamiast obiektowego?
• Jakie są typowe definicje problemów, w których programowanie funkcjonalne jest lepszym wyborem?

Kiedy wybierasz programowanie funkcjonalne zamiast obiektowego?

Gdy spodziewasz się innego rodzaju ewolucji oprogramowania:

• Języki zorientowane obiektowo są dobre, gdy masz ustalony zestaw operacji na rzeczach , a wraz z rozwojem kodu dodajesz przede wszystkim nowe rzeczy. Można to osiągnąć przez dodanie nowych klas, które implementują istniejące metody, a istniejące klasy pozostawia się w spokoju.

• Języki funkcjonalne są dobre, gdy masz stały zestaw rzeczy , a wraz z ewolucją kodu dodajesz przede wszystkim nowe operacje na istniejących rzeczach. Można to osiągnąć przez dodanie nowych funkcji, które obliczają z istniejącymi typami danych, a istniejące funkcje są pozostawione same sobie.

Kiedy ewolucja idzie w złym kierunku, masz problemy:

• Dodanie nowej operacji do programu obiektowego może wymagać edycji wielu definicji klas w celu dodania nowej metody.

• Dodanie nowego rodzaju rzeczy do programu funkcjonalnego może wymagać edycji wielu definicji funkcji, aby dodać nowy przypadek.

Problem ten jest dobrze znany od wielu lat; w 1998 roku Phil Wadler nazwał to „problemem ekspresji” . Chociaż niektórzy badacze uważają, że problem z ekspresją można rozwiązać za pomocą takich cech językowych, jak mixiny, powszechnie akceptowane rozwiązanie nie znalazło się jeszcze w głównym nurcie.

Jakie są typowe definicje problemów, w których programowanie funkcjonalne jest lepszym wyborem?

Języki funkcjonalne przodują w manipulowaniu danymi symbolicznymi w formie drzewa. Ulubionym przykładem są kompilatory, w których języki źródłowy i pośredni zmieniają się rzadko (głównie te same rzeczy ), ale autorzy kompilatorów zawsze dodają nowe tłumaczenia i ulepszenia lub optymalizacje kodu (nowe operacje na rzeczach). Kompilacja i tłumaczenie są bardziej „zabójczymi aplikacjami” dla języków funkcjonalnych.

Niekoniecznie musisz wybierać między tymi dwoma paradygmatami. Możesz pisać oprogramowanie z architekturą OO, używając wielu koncepcji funkcjonalnych. FP i OOP mają charakter ortogonalny .

Weźmy na przykład C #. Można powiedzieć, że jest to głównie OOP, ale istnieje wiele koncepcji i konstrukcji FP. Jeśli wziąć pod uwagę Linq , najważniejsze konstrukcje, które pozwalają na istnienie Linq, mają charakter funkcjonalny: wyrażenia lambda .

Kolejny przykład, F #. Można powiedzieć, że jest to głównie FP, ale dostępnych jest wiele koncepcji i konstrukcji OOP. Możesz definiować klasy, klasy abstrakcyjne, interfejsy, zajmować się dziedziczeniem. Zmienności można używać nawet wtedy, gdy kod jest bardziej przejrzysty lub gdy znacznie zwiększa wydajność.

Wiele współczesnych języków jest paradygmatem.

Zalecane odczyty

Ponieważ jestem na tej samej łodzi (tło OOP, uczę się FP), zasugeruję Ci kilka lektur, które naprawdę doceniam:

• Programowanie funkcjonalne do codziennego programowania .NET , autor: Jeremy Miller. Świetny artykuł (choć źle sformatowany) pokazujący wiele technik i praktyczne, rzeczywiste przykłady FP na C #.

• Real-World Functional Programming , Tomas Petricek. Świetna książka, która zajmuje się głównie koncepcjami FP, próbując wyjaśnić, jakie są, kiedy należy je wykorzystać. Istnieje wiele przykładów zarówno w języku F #, jak i C #. Również blog Petříček za to doskonałym źródłem informacji.

Programowanie obiektowe oferuje:

1. Encapsulation, to
   • kontrola mutacji stanu wewnętrznego
   • ograniczenie sprzężenia do reprezentacji wewnętrznej
2. Subtyping, umożliwiający:
   • podstawienie kompatybilnych typów (polimorfizm)
   • prymitywny sposób dzielenia się implementacją między klasami (dziedziczenie implementacji)

Programowanie funkcjonalne, w Haskell, a nawet w Scali, może pozwolić na podstawienie poprzez bardziej ogólny mechanizm klas typów. Zmienny stan wewnętrzny jest albo odradzany, albo zabroniony. Można również osiągnąć enkapsulację reprezentacji wewnętrznej. Dobre porównanie patrz Haskell vs OOP .

Twierdzenie Normana, że ​​„Dodanie nowego rodzaju rzeczy do programu funkcjonalnego może wymagać edycji wielu definicji funkcji w celu dodania nowego przypadku”. zależy od tego, jak dobrze kod funkcjonalny zastosował klasy typów. Jeśli dopasowanie wzorca dla określonego abstrakcyjnego typu danych jest rozłożone w bazie kodu, rzeczywiście będziesz cierpieć z powodu tego problemu, ale być może jest to kiepski projekt na początek.

ZMIENIONO Usunięto odniesienie do niejawnych konwersji podczas omawiania klas typów. W Scali klasy typów są kodowane za pomocą parametrów niejawnych, a nie konwersji, chociaż konwersje niejawne są kolejnym sposobem uzyskania substytucji kompatybilnych typów.

1. Jeśli pracujesz w silnie współbieżnym środowisku, przydatne jest programowanie czysto funkcjonalne. Brak stanu zmiennego czyni współbieżność prawie banalną. Zobacz Erlang.

2. W języku multiparadygmatu możesz chcieć modelować niektóre rzeczy funkcjonalnie, jeśli istnienie stanu zmiennego jest szczegółem implementacyjnym, a zatem FP jest dobrym modelem dla dziedziny problemowej. Na przykład zobacz opisy list w języku Python lub std.range w języku programowania D. Inspirowane są one programowaniem funkcjonalnym.