Co sądzisz o OOP?

OOP - Aplikacja skacze po całym kodzie z kąta w kąt i uprawia parkour między folderami, zamiast lecieć z góry na dół. W ten sposób nie trzeba mieć jednego pliku z milionem linijek.

Ten komentarz o Javie i OOP mówi wszystko. "Java sucks and it always has. It's that simple. Additionally, every piece of Java code I've encountered has been over engineered. It's nuts. Go 10 levels deep into function calls to find two lines of code. Then back up the call stall and then down again.. and repeat... and repeat... until driven mad. It's as bad as spaghetti code."

Drzewiec napisał(a):

OOP - Aplikacja skacze po całym kodzie z kąta w kąt i uprawia parkour między folderami, zamiast lecieć z góry na dół. W ten sposób nie trzeba mieć jednego pliku z milionem linijek.

Ja preferuję obiekty, dajmy na to zwykłe połączenie do serwera typu GET/POST.

To wolę jak jakiś obiekt się zajmuje tym i nazywa się np. HttpsConnection czy inaczej, ale enkapsuluje wszystko, a nie, że teraz ja muszę sockety konfigurować, ssl tunnel zrobić na tym tcp, http sparsować i zmapować na jakąś strukturę, w sumie mógłbym funkcję przypominającą konstruktor zrobić, czułbym, że muszę wszystko kontrolować.

A tak jest otestowany jakiś obiekt, który ma swoją odpowiedzialność, ja tylko korzystam z fasady jaką on mi daje, nie muszę się przejmować tym jak jest zaimplementowany, nawet zwykle nie ma czasu bo każdy chce wszystko jak najszybciej to od zera nic nie napiszesz, zawsze bazujesz na jakiś gotowych narzędziach, bibliotekach.

Ja tam lubię jak obiektowo jest kod napisany, można też tak strukturami napisać, ale wtedy trzeba explicit przekazywać wskaźnik, w obiektach jest implicit przez rejestr czasem stos, który jest traktowany jako this.

Myślimy że nie powstało nic lepszego niż dobrze zaprojektowane OOP. Tylko ta przeklęta rozwlekła Java która miała nazywać się Oak czyli Dąb je wszystkim obrzydziła.
Dobrze zaprojektowany język z OPP jak Ruby, Dart, czy nawet poprawiony C# jest wygodnym narzędziem. Te wszystkie Rusty, Haskelle, Scala 3 raczej nie zdobędą dużego rynku.
Większość ludzi bez autyzmu/aspergera myśli Obiektowo, a nawet sam John Carmack z autyzmem też lubi obiektowy C++.

coffescript napisał(a):

Większość ludzi bez autyzmu/aspergera myśli Obiektowo, a nawet sam John Carmack z autyzmem też lubi obiektowy C++.

Co rozumiesz przez "myśli obiektowo"? Możesz przedstawić jakąś sytuację z życia, np. planowanie sobie pracy, czy ogólnie dnia/tygodnia/miesiąca, na której mógłbyś zobrazować, jak to obiektowe myślenie większości ludzi może wyglądać? Bo moim zdaniem typowe myślenie jest bardzo odległe od modelu obiektowego.

@Troll anty OOP sorry, ale mnie się zdaje, że ludzie rzeczywiście, by default, myślą obiektowo.

Prosty przykład: Ja piszę długopisem list na kartce.

Ja - podmiot. Piszę - orzeczenie. Długopis, kartka - okoliczniki. list - dopełnienie.

Podmiot.Orzeczenie(przydawka/dopełnienie/okolicznik, przydawka/dopełnienie/okolicznik, przydawka/dopełnienie/okolicznik);

Zatem: I.Write(letter, pen, paper);

proste jak drut?

Pozornie tak. I dlatego ludzie idą w OOP.

ALe jednak nie jest proste. Bo teraz się okazuje, że według OOP this to powinien być nie podmiot, ale mutowany obiekt.

Paper.Write(I, letter, pen); - OK, to się staje coraz mniej intuicyjne.

A teraz się pokazuje, że letter oraz pen powinny być przekazywane przez DI, a w ogóle to klasa Me (której instacją jest I) łamie SRP. A paper to nie jest obiekt, tylko jakaś fabryka.

I nagle pokazuje się, że OOP takie intuicyjne jednak nie jest. Wbrew pozorom nie przekłada się tak prosto na naturalny szyk zdania, jak by się zdawało.

coffescript napisał(a):

Myślimy że nie powstało nic lepszego niż dobrze zaprojektowane OOP. Tylko ta przeklęta rozwlekła Java która miała nazywać się Oak czyli Dąb je wszystkim obrzydziła.
Dobrze zaprojektowany język z OPP jak Ruby, Dart, czy nawet poprawiony C# jest wygodnym narzędziem. Te wszystkie Rusty, Haskelle, Scala 3 raczej nie zdobędą dużego rynku.

Myślę, że to jest klasyczna kwestia bariery wejścia. Niska bariera wejścia = niska inwestycja na wejściu = ludzie w to wchodzą. Wysoka bariera wejśca (brak intuicyjności) = ludzie tego unikają. Niestety, to, co ma wysoką barierę wejścia MOŻE dawać najlepsze wyniki na wyjściu.

Więc mamy:

• Pseudo-OOP: cowboy coding, spaghetti code - niska bariera wejścia, dobrze się sprawdza przy małych projektach (pozwala szybko pisać kod): ludzie w to idą. Niestety, bardzo szybko kod staje się tak nieznoścny, że nie da się z nim pracować. Na ciężkie nieszczęście pewna sprawność w produkowaniu spaghetti code'u jest pewnym lokalnym maksimum, a kto wpadł w lokalne maksimum, może nie widzieć potrzeby szukać dalej - stąd fenomen tzw. "expert beginner", programistów, którzy doświadczeniem jakąś tam sprawność osiągnęli, niestety, tworzą piekło dla wszystkich, którzy później muszą się p...ić z efektami ich prac.
• OOP tak, jak zdefiniowali to Martin, Fowler, Feathers, Beck i inni w swych książkach: bardzo nieuintuicyjne, wysoka bariera wejścia, eksplozja w LoC, ale jest to jakiś sposób organizacji kodu, co więcej, ludzie, którzy są przyzwyczajeni do "OOP na pałę, cowboy coding w pseudo-OOP" z tego tytułu mają nieco obniżoną barierę wejścia do "prawdziwego, Wujko-Bobowego" OOP - bardzo nieuintuicyjne na wejściu, ale ludzie, którzy już się przyzwyczaili do Pythonowego pseudo-OOP i zrozumieli, że pokłady spaghetti code nie są rozwiązaniem, idą w to i stają się wyznawcami.Daje lepsze(!) rezultaty niż produkowanie pokładów spaghetti code'u pomimo olbrzymiego (i to naprawdę olbrzymiego) wymaganego dodatkowego nakładu pracy.
• Programowanie funkcyjne (Haskell itp) - być może najlepszy sposób, jaki obecnie znamy. Daje najlepsze rezultaty i nie wymaga aż tak gigantycznego nakładu pracy, jak prawdziwe OOP. Niestety, jest skrajnie nieuntuicyjne na wejściu i trudne do nauczenia się. "Prawdziwe" OOP to takie lokalne maksimum, dlatego ludzie, którzy w nie weszli, mogą nie chcieć szukac dalej. Ale kto przebrnie przez wysoką barierę wejścia programowania funkcyjnego moze już nigdy nie chcieć wrócić do jakichkolwiek alternatyw. Tyle, że ludzie nie chcą na wejściu kłaść ogromnych pokładów pracy, by zrozumiec skrajnie nieintuicyjny paradygmat i jest to zachowanie w pełni zrozumiałe i racjonalne.

A przynajmniej tak mi się zgaduje.

OOP - fantastyczny paradygmat. Od kiedy się go nauczyłem używam zawsze. Dzięki niemu napisałem setki aplikacji i zaprojektowałem dziesiątki systemów.

Obiektowe podejście pomaga w komunikacji między klientem a programistami. Narzędzia do projektowania jeszcze bardziej ułatwiają proces tworzenia i systematyzowanie informacji. Nie zamienię go w życiu na nic innego (sporadycznie na rzecz strukturalnego dla malutkich programów narzędziowych).
OOP sprawdza się, działa, nie mam i nigdy nie miałem z nim żadnych problemów. Dziedziczenie, polimorfizm, możliwość tworzenia abstrakcji, łatwość przenoszenia klas na struktury bazy, łatwość rozdzielania zadań po ustaleniu interfejsów. To wszystko zaspokaja wszelkie moje potrzeby podczas projektowania systemu a także podczas implementacji.

.. a to, że ktoś sobie w tym "nafajdał" i się pogubił to nie wina OOP tylko tego, że jest bałaganiarzem i niechlujem.

Nie twierdzę też, że inne paradygmaty w pewnych zastosowaniach nie są lepsze ale dla mnie dla współpracy z biznesem nie ma nic bardziej sensownego.
Nie podoba się komuś OOP - to niech pisze inaczej.

@YetAnohterone

być może najlepszy sposób, jaki obecnie znamy. Daje najlepsze rezultaty

Według jakiej metryki?

@YetAnohterone

Metryki z d**y. Dlatego napisałem: BYĆ MOŻE. To nie jest w pełni mierzalne. Zgaduję tylko

To mogłeś to wyraźnie, jak w powyższym komentarzu, w poście napisać.

YetAnohterone napisał(a):

sorry, ale mnie się zdaje, że ludzie rzeczywiście, by default, myślą obiektowo.

IMO popełniasz błąd taki, że skoro sam wykształciłeś w sobie umiejętność modelowania obiektowego to uznajesz, że wszyscy tak mają. Ludzie raczej tworzą w głowie listę instrukcji i if-ów, a nie modelują rzeczywistość w sposób obiektowy.

Np. w przypadku opisywanym przez ciebie model wyglądałby tak:

1. Znajdź kartkę
2. Znajdź długopis
3. Wymyśl zdanie
4. Zapisz zdanie na kartce

O ile w pewnych warunkach ktoś może pomyśleć o sobie w sposób obiektowy (tj. taki, że jest osobą zdolną za pomocą długopisu pisać na kartce) o tyle w życiu codziennym przy wykonywaniu czynności działamy raczej za pomocą list instrukcji. To jest dla ludzi naturalne, natomiast modelowanie rzeczywistości za pomocą abstrakcyjnych modeli - niezależnie czy to będzie modelowanie obiektowe, przepływowe czy jakieś inne - jest nienaturalne.

YetAnohterone napisał(a):

@Troll anty OOP sorry, ale mnie się zdaje, że ludzie rzeczywiście, by default, myślą obiektowo.

Prosty przykład: Ja piszę długopisem list na kartce.

Napiszę w pierwszej osobie, jak ja myślę, niech sobie czytający sami ocenią, czy jest to myślenie typowe dla ludzi, czy unikalne. Są dwa główne przypadki, kiedy piszę list.

1. Mam w głowie myśl, że chcę drugiej osobie przekazać określone informacje, lub moje wrażenia pod wpływem jakiegoś zdarzenia. Mój umysł skupia się na treści, która jest do przekazania. Wzięcie kartki i długopisu, albo siadanie przy komputerze, jest tu czynnością wykonywaną bez zastanawiania się nad tym. Moje myślenie jest zorientowane na przekazywanie treści, nie na obiekty, które do tego przekazywania zostaną użyte. Nie jest to więc myślenie "zorientowane obiektowo".
2. Muszę napisać do kogoś list (maila), bo mam takie zobowiązanie, np. muszę komuś odpowiedzieć. Tutaj moje myślenie zorientowane jest na jak najdokładniejsze przeanalizowanie, o czym powinienem wspomnieć a co lepiej pominąc. Jak sformułować swoją wypowiedź, aby jednocześnie była uprzejma, oraz abym sam się nie wkopał w nadmierne dodatkowe obowiązki. Tutaj też, pomimo że używane są narzędzia - komputer z urządzeniami wejścia/wyjścia, urządzenia sieciowe, oprogramowanie realizujące określony protokół sieciowy - to ich użycie jest automatyczne, prawie całkowicie pomijające świadomy umysł.

Moje myślenie jest zorientowane czynnościowo, a nie obiektowo.

Weźmy teraz pod uwagę przykład, że zamiast samemu pisać jakiś list (lub maila), proszę znajomego aby to zrobił. Prośba będzie w stylu: "napisz im że,... wspomnij o..., nie poruszaj tematu X...". Prośba nie będzie sformułowana w stylu: "usiądź na krześle lub innym obiekcie służącym do siedzenia, na wprost mebla na którym znajduje się komputer z urządzeniami wejścia/wyjścia, połączeniem do internetu i programem pocztowym, po czym..." - to drugie byłoby zorientowaniem obiektowym, pierwsze - nie jest.