Programowanie funkcyjne a programowanie obiektowe [zamknięte]
Do tej pory zajmowałem się głównie programowaniem OO i z niecierpliwością czekam na naukę języka funkcjonalnego. Moje pytania to:
- Kiedy wybrać Programowanie funkcyjne zamiast obiektowe?
- Jakie są typowe definicje problemów, w których programowanie funkcyjne jest lepszym wyborem?
4 answers
Kiedy wybrać Programowanie funkcyjne zamiast obiektowe?
Kiedy przewidujesz inny rodzaj ewolucji oprogramowania:
Języki obiektowe są dobre, gdy masz stały zestaw operacji na rzeczach , a w miarę rozwoju kodu dodajesz przede wszystkim nowe rzeczy. Można to osiągnąć poprzez dodanie nowych klas, które implementują istniejące metody, a istniejące klasy są pozostawione same sobie.
Funkcjonalne języki są dobre, gdy masz stały zestaw rzeczy, a w miarę rozwoju kodu, dodajesz przede wszystkim nowe operacje na istniejących rzeczach. Można to osiągnąć poprzez dodanie nowych funkcji, które obliczają z istniejącymi typami danych, a istniejące funkcje pozostają same.
Kiedy ewolucja idzie w złą stronę, masz problemy:
Dodanie nowej operacji do programu obiektowego może wymagać edycji wielu definicji klas, aby dodać nową metoda.
Dodanie nowego rodzaju rzeczy do funkcjonalnego programu może wymagać edycji wielu definicji funkcji, aby dodać nowy przypadek.
Jakie są typowe definicje problemów gdzie Programowanie funkcyjne jest lepszym wyborem?
Języki funkcyjne sprawdzają się w manipulowaniu danymi symbolicznymi w postaci drzewa. Ulubionym przykładem są Kompilatory, gdzie języki źródłowe i pośrednie 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). Kompilacji i tłumaczenia ogólnie są "killer apps" dla funkcjonalnych języki.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-09 08:11:56
Niekoniecznie musisz wybierać pomiędzy tymi dwoma paradygmatami. Można pisać programy o architekturze OO używając wielu pojęć funkcjonalnych. FP i OOP mają charakter ortogonalny .
Weźmy na przykład C#. Można powiedzieć, że to głównie OOP, ale istnieje wiele koncepcji i konstrukcji FP. Jeśli weźmiemy pod uwagę Linq, Najważniejsze konstrukcje, które pozwalają na istnienie Linq są funkcyjne w naturze: wyrażenia lambda.
Kolejny przykład, F#. Można powiedzieć jest to głównie FP, ale dostępnych jest wiele koncepcji i konstrukcji OOP. Możesz definiować klasy, klasy abstrakcyjne, interfejsy, zajmować się dziedziczeniem. Można nawet użyć zmienności, gdy sprawia, że kod jest bardziej przejrzysty lub gdy znacznie zwiększa wydajność.
Wiele współczesnych języków jest wielowymiarowych.
Zalecane lektury
Jako, że jestem w tej samej łodzi (tło OOP, nauka FP), proponuję ci jakieś odczyty, które naprawdę doceniane:
Programowanie funkcjonalne do codziennego rozwoju. NET, autor: Jeremy Miller Świetny artykuł (choć słabo sformatowany) pokazujący wiele technik i praktycznych, rzeczywistych przykładów FP na C#.
Programowanie funkcjonalne w świecie rzeczywistym, Autor: Tomas Petricek Świetna książka, która zajmuje się głównie pojęciami FP, starając się wyjaśnić czym one są, kiedy powinny być używane. Istnieje wiele przykładów zarówno w F # jak i C#. Również, [[31]} Blog Petricka jest doskonałym źródłem informacji.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-09 08:10:07
Programowanie obiektowe oferuje:
- enkapsulacja, do
- mutacja kontrolna stanu wewnętrznego
- sprzężenie graniczne do reprezentacji wewnętrznej
- Podtyp, pozwalający:
- zastępowanie typów zgodnych (polimorfizm)
- surowy sposób dzielenia implementacji między klasami (dziedziczenie implementacji)
Programowanie funkcyjne, w Haskell czy nawet w Scali, pozwala na zastępowanie przez więcej ogólny mechanizm klas typów. Zmienny stan wewnętrzny jest albo zniechęcany, albo zabroniony. Można również osiągnąć hermetyzację reprezentacji wewnętrznej. Zobacz Haskell vs OOP dla dobrego porównania.
Twierdzenie Normana, że " dodanie nowego rodzaju rzeczy do programu funkcjonalnego może wymagać edycji wielu definicji funkcji, aby dodać nowy przypadek."zależy od tego, jak dobrze kod funkcjonalny zastosował klasy typu. Jeśli dopasowanie wzorca na danym abstrakcyjnym typie danych jest rozłożone w całej bazie kodowej rzeczywiście będziesz cierpieć z powodu tego problemu, ale być może jest to kiepski projekt na początek.
Edytowano usunięto odniesienie do niejawnych konwersji podczas omawiania klas typów. W Scali klasy typów są kodowane z parametrami niejawnymi, a nie konwersjami, chociaż konwersje niejawne są kolejnym sposobem na zastąpienie zgodnych typów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-02-18 14:08:33
Jeśli jesteś w środowisku silnie współbieżnym, użyteczne jest czyste programowanie funkcjonalne. Brak zmiennego stanu sprawia, że współbieżność jest niemal trywialna. # Patrz Erlang
W języku wieloparadigm można modelować pewne rzeczy funkcjonalnie, jeśli istnienie stanu zmiennego jest szczegółem implementacji, a zatem FP jest dobrym modelem dla domeny problemu. Na przykład patrz składanie list w Pythonie lub std.zakres w programowaniu D język. Są one inspirowane programowaniem funkcjonalnym.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-01-16 21:41:00