Mamy różne paradaygmaty, które są wspierane przez jezyki programowanie, jedne wspierają lepiej lub gorzej OOP, niektóre FP, a jeszcze inne DOP. Czy ktoś mógłby podsumować kiedy jakie paradygmat lepiej się sprawdza się używać, najlepiej na podstawie własnych doświadczeń, bo tak ogólnie to każdy z tych paradygmatów ułatwia pisanie złożonych i testowalnych programów, natomiast jak to jest w praktyce? Czy ktokolwiek przed pisaniem programu zastanawia się jaki paradygmat do wybrnego projektu lepiej się zga? Fajnie byłoby gdyby ktoś przedstawił wady / zalety w zalezności od typu tworzonego oprogramowania. Dzięki :-)
0
1
Mamy różne paradaygmaty, które są wspierane przez jezyki programowanie, jedne wspierają lepiej lub gorzej OOP, niektóre FP, a
Pytanie tylko "czym jest OOP" i co to znaczy "wspiera lepiej lub gorzej"? To jest subiektywne, zależy co ktoś ma na myśli przez OOP, jaką wizję obiektówki ma w głowie(choćby podział na dynamiczne vs. statyczne języki). Tak samo FP dla jednego będą to operacje na niemutowalnych kolekcjach i to mu wystarczy, a inny będzie szukał abstrakcji rodem z Haskella. A DOP znaczy data oriented programming? To przecież ani OOP ani FP temu nie przeszkadza.
natomiast jak to jest w praktyce? Czy ktokolwiek przed pisaniem programu zastanawia się jaki paradygmat do wybrnego projektu lepiej się zga
W praktyce ludzie piszą tak, jak lubią i umieją, czasami tu i ówdzie eksperymentując. No i w mainstreamowym programowaniu paradygmaty się mieszają zwykle. Nic nie stoi na przeszkodzie, żeby stworzyć np. apkę obiektową z dodatkiem programowania funkcyjnego.
To trochę jak smażenie/gotowanie. Będą zwolennicy, żeby tylko gotować i nic nie będą smażyć, bo "smażenie niezdrowe", będą ludzie, który wrzucą coś na patelnię, podsmażą i zjedzą, a równie dobrze można wypośrodkować i robiąc jedną potrawę najpierw obsmażyć mięso, a potem je ugotować. Albo nawet można upiec mięso (analogicznie: można znaleźć jeszcze inny paradygmat, który nie będzie niczym z tych, co wymieniłeś).
4
pojęcia OPP, FP, DOP są zdefiniowane, i jednoznacznie określają co w danych paradygmatach jest priorytetem
Nie, nie są.
- OOP ma dwie definicje pierwszą (radykalną) oraz popularną (liberalną). Pierwszą spełnia tylko SmallTalk i Ruby. Popularną spełnia C++, Java i reszta barachła.
- Definicja FP jest tak bezsensowna i niepraktyczna (nic z niej nie wynika) że każdy autor książek o FP i każdy bardziej znany programista ma własną praktyczną definicję FP
BTW wiele języków jest wstanie spełnić liberalną definicję OOP i liberalną definicję FP jak Clojure, Scala, OCaml, F# czy Reason. Są też języki co do których określenie obiektowe jest kontrowersyjne jak Rust, Haskell i Scheme/Racket, ale po przyjrzeniu się można stwierdzić że z łatwością można pisać w nich kod OOP
0
@KamilAdam:
A możesz wyjaśnić czemu tylko SmallTalk i Ruby są true obiektowe?
Edit:
Chodzi o to?:
A Smalltalk object can do exactly three things:
Hold state (references to other objects).
Receive a message from itself or another object.
In the course of processing a message, send messages to itself or another object.
1
scibi92 napisał(a):
@KamilAdam:
A możesz wyjaśnić czemu tylko SmallTalk i Ruby są true obiektowe?
Edit:
Chodzi o to?:A Smalltalk object can do exactly three things:
Hold state (references to other objects).
Receive a message from itself or another object.
In the course of processing a message, send messages to itself or another object.
Tak, dokładnie o to chodzi. To związku z pracami nad SmallTalkiem zdefiniowano co to jest OOP. Podobno twórcę SmallTalka inspirowało jak komunikują się żywe komórki (wysyłając do siebie sygnały i ukrywając swój stan)