Świetna dyskusja dlaczego OOP ssie.

W komentarzach:
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html

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ą.

Co zatem specjaliści polecą zamiast OOP?

czego oni tak nie lubią tej javy

“If Java had true garbage collection, most programs would delete themselves upon execution.” — Robert Sewell

Dyskusja z przeciwnikami OOP jest jak kłótnia z kobietą - będą wrzeszczeć i wygadywać głupoty dopóki nie przyzna im się racji.

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.

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.

Na temat OOP była już w sumie podobna dyskusja: Czy programowanie obiektowe to najgorszy paradygmat programowania jaki kiedykolwiek wymyślono?

OOP to cos pieknego.

W oczach widac projekt opisany obiektami i wszystko staje sie czytelne i piekne. Po prostu to znaczy wiecej niz 1000 slow, tego opisac sie nie da.

PS
Zlej baletnicy przeszkadza rabek u spodnicy.

Dziekuje i dowidzenia.

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.

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.

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

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.

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).

Zbiór cytatów losowych osób to nie jest dyskusja.

Ja obiektowki nie lubie bo na razie nie bardzo ja umiem ;). Za to kocham programowanie funkcyjne.

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ę :).

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!

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"

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.

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ć.

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.

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!".

Kilka podstawowych przewag programowania proceduralnego nad obiektowym:

• większa swoboda i elastyczność
• łatwiejsze debugowanie
• bardziej intuicyjne

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ś.

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.