@ProceduralMasterRace oraz @Troll anty OOP no i anonim czy mozecie podac powody dla ktorych OOP ssie?
Wielbiciele OOP mają wiele argumentów teoretycznych, ale te argumenty teoretyczne zakładają nierealistyczną, perfekcyjną, wręcz nieludzką naturę idealnego programisty.
Nie, po prostu zdyscyplinowanie i przestrzeganie pewnych reguł, które i tak są mniej ścisłe i mniej ograniczające niż reguły pisania choćby programowania funkcyjnego.
Czysto teoretycznie, jeśli jakieś narzędzie jest na widoku człowieka i wywołuje w nim złudzenie że jest pomocne,
ale w 99% przypadków okazuje się gorsze, a w tym 1% jest trochę lepsze,
to czysto teoretycznie posiadanie tego narzędzia jest czymś dobrym.
Czysto praktycznie - należałoby się takiego narzędzia pozbyć.
Gorsze się okazuje dlatego, że 99% programistów to idioci, którzy klepią bezmyślnie, a tylko 1% coś ogarnia, więc idąc tym tropem, należałoby się w ogóle pozbyć programowania jako takiego. Nie jest problemem OOP, tylko to, że ludzie, którzy nie maja pojęcia o niczym (i powinni siedzieć w piwnicach i się douczać, ew. robić coś na stażu pod okiem ludzi bardziej doświadczonych) programują prawdziwe komercyjne duże rzeczy.
Walczysz z wiatrakami, bo problemem jest niekompetencja ludzka, a nie paradygmat. W każdym paradygmatu będziesz mieć spaghetti.
Te dodatkowe warstwy abstrakcji, których robienie tak ułatwiają języki OOP są taką pułapką,
która na pierwszy rzut oka wydaje się właściwym rozwiązaniem, natomiast w ogromnej ilości przypadków,
po pewnym czasie, okazuje się błędem, z którego ciężko się wycofać,
Jeśli ludzie łamią wszystkie dobre praktyki i zasady, o których piszą w książkach i klepią obiektówkę "na pałę", to zawsze tak się kończy. Spaghetti kodem. Praktyka powinna mieć oparcie w teorii, a teorii o obiektówce nie brakuje, tylko nikt nie chce się słuchać tych zasad.
Ale z drugiej strony teoria powinna mieć pokrycie w praktyce. Ludzie, którzy próbują naśladować bezmyślnie to, co jest w książkach i uczą się na pamięć wzorców projektowych z książki też osiągną porażkę.
Jeśli ktoś jest przeładowany teorią, a brak mu doświadczenia własnego (i własnego rozeznania, co się sprawdza, a co nie), to też stworzy shit.
Rozwiązanie jest proste - programowania należy się po prostu uczyć - częściowo poprzez praktykę, częściowo poprzez teorię, równoważąc jedno z drugim. Taka nauka może zająć kilka, kilkanaście, czy więcej lat, ale w końcu człowiek się nauczy na tyle, żeby było w miarę ładnie. Nikt nie rodzi się programistą i wiadomo, że na początku każdy będzie pisał słaby kod w każdym paradygmacie.
bo programy obiektowe W PRAKTYCE, nie w teorii, mają silniejsze powiązania pomiędzy poszczególnymi swoimi modułami.
No dobra, ale pokazujesz sytuację, w której ktoś nie umie dobrze programować w OOP, wtedy faktycznie wychodzi szambo (przecież obiektówka wymyśliła już recepty na problem powiązań między modułami - Single Responsibility Principle, Separation of concerns, decoupling, dependency inversion...) Poza tym OOP zaczyna się jeszcze przed włączeniem komputera, trzeba pomyśleć nad tym, w jaki sposób moduły/obiekty się między sobą komunikują, w jaki sposób są od siebie zależne i co zrobić, żeby nie były zależne; trzeba też pomyśleć i przewidzieć "co może pierdyknąć za pół roku, rok". Na tym polega OOP, na patrzeniu na projekt zarówno z lotu ptaka jak i na poziomie bardzo mikro (aż do poziomu pojedynczej metody).
To co krytykujesz, to spaghetti kod ludzi, którym wydaje się, że znają OOP, bo przeczytali jedną książkę o tym albo przerobili tutorial, i tworzą śmieciowy kod bez większego przemyślenia, bez rozważenia "za i przeciw" każdej kluczowych decyzji w kodzie. Mają to, co mają potem.
Czyli masz złego nicka, bo w dalszym ciągu nie widzę tu żadnego ataku na OOP, tylko raczej krytykę tego, że w teorii w programowaniu są jakieś zasady, a w praktyce programowaniem zajmują się ludzie niekompetentni, którzy piszą jak chcą. Gdzie tu OOP?
