cerrato napisał(a):
OOP to jedno z podejść/technologii. I nie ma jednoznacznej odpowiedzi, czy jest wporzo, czy raczej kolejnym wcieleniem szatana.
Przede wszystkim - zależy od projektu, nad którym się w danej chwili pracuje.To trochę jak w warsztacie mechanika - koleś ma całą szafę narzędzi i każde nadaje się do czegoś innego.
Klucz nasadowy z grzechotką jest super sprawą, ale raczej nie przyda się przy wymianie rozbitej szyby ;)
OOP to bardziej taka grzechotka z kluczem, niż klucz z grzechiotką.
Wibowit napisał(a):
Dyskusja z przeciwnikami OOP jest jak kłótnia z kobietą - będą wrzeszczeć i wygadywać głupoty dopóki nie przyzna im się racji.
O widzisz, to identycznie jak z zaelotami OOPu.
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
Myślę, że mogę śmiało powiedzieć że ktoś kto ma problem z programowaniem obiektowym, będzie też miał pod górkę z programowaniem proceduralnym i funkcyjnym (i ogólnie - z czystym kodem).
Patrząc na definicję języka COBOL można odnieść wrażenie że nie da się w nim nic sp... bo to nawet nie jest język proceduralny - ale to nieprawda.
Są pewne uniwersalne zasady (DRY, SOLID, YAGNI, podwójne zaprzeczenia etc.) których jeśli się nie rozumie to każdy paradygmat będzie bee.
- Rejestracja:ponad 11 lat
- Ostatnio:ponad 4 lata
- Postów:2442
Na temat OOP była już w sumie podobna dyskusja: Czy programowanie obiektowe to najgorszy paradygmat programowania jaki kiedykolwiek wymyślono?
Uczynny Terrorysta napisał(a):
OOP to cos pieknego.
Podobnie jak "czysta rasa aryjska" dla hitlerowców
Zlej baletnicy przeszkadza rabek u spodnicy.
Też to powtarzam jak ktoś zaczyna bulgotać jakie to programowanie proceduralne jest gorsze od obiektowego
Dziekuje i dowidzenia.
No to elo na drogę.
vpiotr napisał(a):
Myślę, że mogę śmiało powiedzieć że ktoś kto ma problem z programowaniem obiektowym, będzie też miał pod górkę z programowaniem proceduralnym i funkcyjnym (i ogólnie - z czystym kodem).
Ło, ale pojechałeś po developerach UNIXowych, oni szkalują OOP bardziej niż karachan papieża. Trudno o nich powiedzieć jednak, by parcując na kodzie o 40letniej nieraz historii tworzyli kod gorszy niż niejeden kiluletni OOPowy makaronik z czołowych korpo i januszeksów. Wręcz bym powiedział, że nad nim gurują o wiele długości piaskownicy.
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
- Postów:4882
w linku sa wypowiedzi ktore jeszcze niektore sa wyrwane z kontekstu np wypowiedz Linus Torvalds (2007) jest o jezyku a nie o OOP :D
argumenty a nie wypowiedzi innych. Argument bo ktos tak powiedzial nie jest argumentem (w tym temacie, odnosze sie do konkretnego przykladu ktory OP podlinkowal). Nawet zeby ten ktos byl najlepszy na swiecie. Bez podania wyjasnienia taki argument (jest domniemany) nie ma znaczenia w dyskusji.
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
Złoty Samiec napisał(a):
vpiotr napisał(a):
Myślę, że mogę śmiało powiedzieć że ktoś kto ma problem z programowaniem obiektowym, będzie też miał pod górkę z programowaniem proceduralnym i funkcyjnym (i ogólnie - z czystym kodem).
Ło, ale pojechałeś po developerach UNIXowych, oni szkalują OOP bardziej niż karachan papieża. Trudno o nich powiedzieć jednak, by parcując na kodzie o 40letniej nieraz historii tworzyli kod gorszy niż niejeden kiluletni OOPowy makaronik z czołowych korpo i januszeksów. Wręcz bym powiedział, że nad nim gurują o wiele długości piaskownicy.
Wypowiedź tak ogólna że dziwię się że nie napisałeś o "amerykańskich uczonych".
A nawet gdybyś kogoś konkretnie zacytował to wyrwane z kontekstu wypowiedzi Twoich autorytetów o niczym nie przesądzają.
http://sciaga.pl/tekst/128235-129-erystyka-przyklady-chwytow-erystycznych
- Rejestracja:około 8 lat
- Ostatnio:3 minuty
- Postów:4884
Można powiedzieć, że mamy w programowaniu dwie metody postępowania: Złożoność i komplikacje schować za interfejsem (oddzielić od użytkownika); Abstrakcję zamykać w oddzielnych kawałkach kodu.
Można to zrealizować różnie, funkcyjnie, obiektowo, proceduralnie. Nawet @Wibowit, popierający zawsze OOP, nie powie Ci, że jest to [OOP] jedyna droga do inżynierii oprogramowania; po prostu jest to wygodne, łatwe(w sumie), rozwinięte i rozpowszechnione. Jak umiesz programować to w każym paradygmacie powtórzysz wzorce. A Ty mógłbyś napisać coś konstruktywnego, zamiast wrzucać linka z cytatami i tworzyć niecenzuralne tagi.
- Rejestracja:ponad 10 lat
- Ostatnio:5 miesięcy
- Lokalizacja:Warszawa
- Postów:3573
No własnie, przecież i obiektowe i proceduralne i funkcyjne mają swoje zastosowania, co więcej łączy się je w językach programowania (np. Scala czy Java).
- Rejestracja:ponad 7 lat
- Ostatnio:ponad 6 lat
- Postów:16
Ja obiektowki nie lubie bo na razie nie bardzo ja umiem ;). Za to kocham programowanie funkcyjne.
- Rejestracja:ponad 7 lat
- Ostatnio:około 6 lat
- Postów:101
Podchodzę do OOP bardziej jak do narzędzia. Po pierwsze, nie ma narzędzi uniwersalnych, które rozwiązują wszystkie problemy świata. Po drugie, w programowaniu oprócz paradygmatów są też pewne hmmm... powiedzmy, że prawa, których ignorowanie prowadzi do kłopotów. Przykładowo, weźmy jedną wypowiedź ze strony:
Rich Hickey (2010)
SE Radio, Episode 158
"I think that large objected-oriented programs struggle with increasing complexity as you build this large object graph of mutable objects. You know, trying to understand and keep in your mind what will happen when you call a method and what will the side effects be."
I pytanie moje brzmi: czy to naprawdę wina OOP, że gość se zbudował w jakimś języku X "large graph of mutable objects", bo mógł? Znam, widziałem i mogę przytoczyć przykład chwalonego projektu, gdzie 60% klas było niezmiennych, zdecydowana większość pozostałych - klasy krótkożyjących obiektów niewychodzących poza jeden wątek, a długożyjące obiekty ze zmiennym stanem można było policzyć na palcach. Różnica w jakości pracy pomiędzy nim, a innym projektem napisanym właśnie jako "large graph of mutable objects" porażająca, a i w jednym, i w drugim było OOP.
Myślę, że część nieporozumień bierze się z tego, że pojęcia takie, jak "programowanie funkcyjne" czy "OOP" funkcjonują w naszych głowach jako mieszanki wielu czasem bardzo odległych od siebie rzeczy i jak coś nie wychodzi, próbujemy oceniać naszą własną, unikalną mieszankę. Dla mnie na przykład paradygmatem przeciwstawnym do programowania funkcyjnego jest raczej programowanie imperatywne. OOP rozwiązuje problem trochę z innej bajki. Często natykam się na projekty napisane w językach "nie-OOP", np. C, czy nawet jakieś języki funkcyjne, gdzie bez trudu da się znaleźć partie kodu, które przy pomocy dostępnych konstrukcji tworzą ni mniej, ni więcej, tylko obiekty :). Można się zarzekać, że nie, że co jak, ale kurde... jeśli coś wygląda jak obiekt i zachowuje się jak obiekt, to najwidoczniej jest obiektem :D. Dlatego właściwsze pytanie brzmi: czy faktycznie do rozwiązania naszego problemu potrzebujemy języka z rozbudowanym narzędziem o nazwie "OOP" czy wystarczy nam zamodelowanie obiektów przy użyciu czegoś innego tam, gdzie ich naprawdę potrzeba, i wykorzystanie zalet innego podejścia?
Oddzielną kwestią jest to, że implementacje OOP dają nam do rąk także narzędzia, co do których praktyka pokazała, że przydają się raczej rzadko (dziedziczenie), a jeśli są nadużywane, naprawdę mogą narobić problemów. Mimo to poświęca się im niewspółmiernie dużo czasu. Ale od istnienia takich min to chyba nic nie jest wolne - mądry człowiek po prostu ich nie używa, jeśli naprawdę nie musi, i po sprawie.
A już tak z trochę innej bajki - trafiłem na blog yegora już kilkakrotnie i hmmm... gość lubi "naginać" różne rzeczy tak, by pasowały do jego światopoglądu. Problem polega na tym, że to się niestety sprzedaje... napisz coś tak, by wywołało kontrowersje i te kontrowersje już pociągną resztę :).
- Rejestracja:prawie 20 lat
- Ostatnio:około 8 godzin
Gwoli ścisłości to "large graph of mutable objects" nie ma nic wspólnego z OOP, no może poza nazwą object. Zamiast object można wstawić strukturę z C czy Rusta i wyjdzie na to samo - dalej będziemy mieć duży graf mutowalnych struktur. Każdy język niefunkcyjny pozwala się łatwo zakopać w takich grafach.
W językach funkcyjnych na upartego można by odtworzyć problemy związane z duzymi mutowalnymi grafami, ale wtedy trzeba tworzyć masę funkcji, które przyjmują i zwracają niepotrzebnie rozbudowane dane.
Często natykam się na projekty napisane w językach "nie-OOP", np. C, czy nawet jakieś języki funkcyjne, gdzie bez trudu da się znaleźć partie kodu, które przy pomocy dostępnych konstrukcji tworzą ni mniej, ni więcej, tylko obiekty :). Można się zarzekać, że nie, że co jak, ale kurde... jeśli coś wygląda jak obiekt i zachowuje się jak obiekt, to najwidoczniej jest obiektem :D.
Świetnie ujęte!
- Rejestracja:prawie 20 lat
- Ostatnio:około 8 godzin
Jeśli chcesz zobaczyć niepotrzebnie skomplikowane twory to wystarczy przejrzeć co bardziej ekstremalne biblioteki funkcyjne, np Haskellowe szaleństwo monadowe bądź cała biblioteka scalaz. A może one wcale nie są ekstremalne? Programowanie funkcyjne tylko na początku jest przystępne, przy przechodzeniu w coraz bardziej zaawansowane konstrukcje traci się poczucie sensu tego wszystkiego. Dlatego ja wolę mieszaninę FP i OOP, jak w Scali.
Simplicity is hard.
- Rejestracja:ponad 12 lat
- Ostatnio:około 3 godziny
- Postów:3539
Uwielbiam te dyskusje purystów :)
Zacznijmy od podstawowych faktów. Twierdzenie, że OOP jest złe i programowanie funkcyjne jest lepsze jest tak samo zasadne, jak twierdzenie, że opony zimowe są gorsze od letnich bo motory fajniej wyglądają od samochodów.
Są trzy paradygmaty programowania związane z przepływem kodu:
- imperatywny (program wykonuje obliczenia w kolejności zadanej przez programistę - czyli czysta Java w starszych wersjach)
- deklaratywny (program wykonuje obliczenia w momencie, kiedy je można wykonać - czyli tak, jak Spring wstrzykuje zależności)
- funkcyjny (program wykonuje obliczenia w momencie kiedy są one potrzebne)
Natomiast programowanie obiektowe wyklucza programowanie strukturalne.
To, że Java jest językiem imperatywno-obiektowym, do którego doklepano różne mechanizmy pozwalające na programowanie deklaratywne (annotacje) lub funkcyjne (cały pakiet java.util.function) nie zmienia faktu, że samo OOP nie ma nic do bycia funkcyjnym. Można wzorem Javy właśnie uznać monady za obiekty i co się stanie? Nic, dalej będzie można składać sobie funkcje w długie łańcuchy. Ot tyle.
Co do argumentu "OOP jest be ponieważ widziałem słaby soft napisany w OOP" - poczekajcie, aż FP stanie się mainstreamowe, wtedy będziecie się zastanawiać gdzie breakpointa postawić.
- Rejestracja:ponad 11 lat
- Ostatnio:prawie 3 lata
wartek01 napisał(a):
Są trzy paradygmaty programowania związane z przepływem kodu:
- imperatywny (program wykonuje obliczenia w kolejności zadanej przez programistę - czyli czysta Java w starszych wersjach)
- deklaratywny (program wykonuje obliczenia w momencie, kiedy je można wykonać - czyli tak, jak Spring wstrzykuje zależności)
- funkcyjny (program wykonuje obliczenia w momencie kiedy są one potrzebne)
???
Skąd ty te definicje sobie wziąłeś? Szczególnie tą funkcyjną.
Ja glownie programuje w pracy w C++, ale w domu chetnie poznaje inne paradygmaty. Gdy uczylem sie F# to zauwazylem, ze moj kod C++ w pracy staje sie coraz mniej obiektowy i coraz bardziej proceduralny i funkcyjny (na ile to C++ pozwala). Wciaz uzywalem klas ale w znacznie mniejszym stopniu niz robilem to kiedys.
- Rejestracja:ponad 12 lat
- Ostatnio:około 3 godziny
- Postów:3539
Fedaykin napisał(a):
wartek01 napisał(a):
Są trzy paradygmaty programowania związane z przepływem kodu:
- imperatywny (program wykonuje obliczenia w kolejności zadanej przez programistę - czyli czysta Java w starszych wersjach)
- deklaratywny (program wykonuje obliczenia w momencie, kiedy je można wykonać - czyli tak, jak Spring wstrzykuje zależności)
- funkcyjny (program wykonuje obliczenia w momencie kiedy są one potrzebne)
???
Skąd ty te definicje sobie wziąłeś? Szczególnie tą funkcyjną.
Z książki której tytułu nie pamiętam (dawno temu) o architekturze procesorów.
Co do funkcyjności - wykonywanie obliczeń w momencie gdy są potrzebne oznacza, że coś jest lazy-evaluated. A funkcje z definicji powinny być lazy-evaluated.
https://wiki.haskell.org/Lazy_evaluation
Lazy evaluation is a method to evaluate a Haskell program. It means that expressions are not evaluated when they are bound to variables, but their evaluation is deferred until their results are needed by other computations. In consequence, arguments are not evaluated before they are passed to a function, but only when their values are actually used.
Z drugiej strony:
https://wiki.haskell.org/Eager_evaluation
Eager evaluation is an implementation of the strict semantics as can be found in OCaml and usually in imperative languages.
Hanibal napisał(a):
Ktoś mądry napisał w necie o obiektówce coś takiego
"połowę rzeczy w programowaniu obiektowym jest łatwe i intuicyjne, druga połowa jest nieintuicyjna, i niepotrzebnie skomplikowana"
To raczej szło tak:
“The phrase "object-oriented” means a lot of things. Half are obvious, and the other half are mistakes.“ – Paul Graham
"Termin ''zorientowane obiektowo'' mieści w sobie wiele rzefczy. Połowa z nich jest oczywista, reszt jest pomyłką " – Paul Graham
Trzeźwy Karp napisał(a):
Ja glownie programuje w pracy w C++, ale w domu chetnie poznaje inne paradygmaty. Gdy uczylem sie F# to zauwazylem, ze moj kod C++ w pracy staje sie coraz mniej obiektowy i coraz bardziej proceduralny i funkcyjny (na ile to C++ pozwala). Wciaz uzywalem klas ale w znacznie mniejszym stopniu niz robilem to kiedys.
No i bardzo dobrze. Tworzenie klas do wszystkiego co się da w obecnych czasach to plaga. Zwłąszcza im młodsze pokolenie, tym bardziej wypaczone mózgi. Jeszcze trochę a dojdziemy do poziomu, gdzie będą tworzyć hierarchię klas, żeby tylko napisać program "Hello Wordl!".
- Rejestracja:prawie 20 lat
- Ostatnio:około 8 godzin
Błękitny Kot napisał(a):
Kilka podstawowych przewag programowania proceduralnego nad obiektowym:
- większa swoboda i elastyczność
- łatwiejsze debugowanie
- bardziej intuicyjne
Nie zgadzam się z żadnym z punktów. Uzasadnienia nie chce mi się podawać, bo sam uzasadnienia nie podałeś.
- Rejestracja:około 8 lat
- Ostatnio:3 minuty
- Postów:4884
Błękitny Kot napisał(a):
Kilka podstawowych przewag programowania proceduralnego nad obiektowym:
- większa swoboda i elastyczność
- łatwiejsze debugowanie
- bardziej intuicyjne
A dodatkowy bonus to spaghetti przy większym projekcie:)
lion137 napisał(a):
Błękitny Kot napisał(a):
Kilka podstawowych przewag programowania proceduralnego nad obiektowym:
- większa swoboda i elastyczność
- łatwiejsze debugowanie
- bardziej intuicyjne
A dodatkowy bonus to spaghetti przy większym projekcie:)
A nie dorzucali do tego klopsików? Spagehetti powstanie w każdym paradygmacie.