Wątek przeniesiony 2019-07-29 15:33 z przez cerrato.

Nie rozumiem sensu programowania obiektowego

Odpowiedz Nowy wątek
2019-07-29 14:57
0

Zacznę o zastrzeżenia, że nie zamierzam, tu wszczynać wojny ideologicznej. Jak piszę, że czegoś nie rozumiem, oznacza to, że czegoś nie rozumiem, a nie że rzucam formalne wyzwanie wyznawcom odmiennego paradygmatu ;) Poza tym wiem też, że jestem po prostu hobbystką i zdaję sobie z tego sprawę, więc nie trzeba mi ani przypominać ani udowadniać ;)

Teraz w ramach wprowadzenia: mam ze 20 lat praktyki w rzeźbieniu czegoś tam w necie, ale zawsze robiłam to sobie na własny rachunek i bardzo "po swojemu", co tłumaczy, że:

Nie kumam sensu obiektówki :/ Rozumiem sensowność takiego podejścia w sytuacji, kiedy faktycznie mam manipulować na jakichś obiektach (np. elementach strony internetowej czy symulacji floty statków różnej klasy od czego podobno zaczęła się cała idea). Nie mam natomiast pojęcia do czego mi to w sytuacji typowych zastosowań, do których używam kodu:

  • policzyć coś i wyświetlić / zapisać,
  • wczytać dane z pliku, policzyć i wyświetlić / zapisać,
  • obsłużyć formularz / cms na stronie www.

W ciągu ostatnich kilkunastu lat robiłam do sprawy kilka podejść. Oglądałam jakieś przykłady prezentujące definiowanie klas zwierzątek albo samochodów, ich właściwości, metod, dziedziczenia i wszystko to rozumiem. Nie rozumiem natomiast po ch... mi to :/ jak niby i po co mam tego użyć w wymienionych powyżej zastosowaniach. Tymczasem autorzy po dojściu do tego etapu, wychodzą z założenia, że już wszystko wytłumaczyli. Więc kończy się zawsze tak, że po prostu wzruszam ramionami i piszę sobie dalej "po swojemu".

Rozumiem celowość tworzenia programu jako hierarchii pudełek przekazujących sobie parametry, ale (w moim mniemaniu) podobny efekt daje się uzyskać programowaniem proceduralnym, tworząc odpowiednią strukturę funkcji.

W dyskusjach odnośnie pojawia się dosyć często kwestia dziedziczenia i argument, że to ułatwia utrzymanie dużych projektów. Być może, nie będę się spierać, nie mając praktyki w dodawaniu kolejnych cegiełek do cudzych, rozległych systemów.


I teraz pytania:

Czy komuś chciałoby się poświęcić czas na ukazanie kilku elementarnych, praktycznych (nie zaś zwierzątkowo-abstrakcyjnyc) przykładów zastosowania programowania obiektowego z wytłumaczeniem dlaczego akurat tak?

Czy paradygmat obiektowy jest czymś uniwersalnym? Bo mam wrażenie, że to co może faktycznie się sprawdzać przy dużych projektach zastosowane dla zrobienia zwykłego "Witaj świecie" albo czegoś podobnego, to zwykłe przeinżynierowanie?

Ew. wszelkie inne uwagi odnośnie moich lamerskich wywodów.


edytowany 2x, ostatnio: Freja Draco, 2019-08-10 20:59
Pokaż pozostałe 9 komentarzy
Nie, tak nie miewam. Ogólnie jestem bardziej nastawiony na poprawianie tekstu niż "obrazków"; nie wiem w sumie, czemu. Nie lubię, gdy ktoś opuszcza jakieś zasady "bez powodu" (tzn. "równie dobrze" mógłby ich nie opuścić). - Silv 2019-07-29 15:13
I gdybyś podała mi wiarygodny (dla mnie) powód, dla którego napisałaś tytuł małą literą, byłoby to dla mnie równoznaczne z napisaniem go wielką, przynajmniej w sensie formalnym. - Silv 2019-07-29 15:15
Lubię też porządek, np. w pokoju. Gdy wszystko jest na swoim miejscu. To chyba powiązane z zasadami. - Silv 2019-07-29 15:27
że ty też miewasz czasem tak, że nie możesz się skupić, bo na ścianie jest kropka i kombinujesz, jak by można ją zetrzeć? Lol. Też coś takiego mam, chociaż właśnie jeśli chodzi o literówki. - LukeJL 2019-07-29 15:30
Może po prostu nie odpowiada taki styl programowania obiektowego jaki jest w C#, Java lub Kotlin. W Rust i Go jest trochę inaczej, zakochałem się w kodzeniu w Rust, najlepiej zaprojektowany język jaki widziałem. - sanny 2019-07-29 15:57

Pozostało 580 znaków

2019-07-31 02:33
5
PerlMonk napisał(a):

A no w taki, że jeśli chcesz nazwać kod obiektowym, to logika programu musi w jakiś sposób te obiekty reprezentować.

Owszem, muszą być obiekty. Inaczej nie byłoby sensu nazywać tego obiektowym, to chyba logiczne?

Wyobraź sobie (czego ja oczekuję...), że w kodzie C++ nie użyjesz słów kluczowych struct, class i static do napisania kodu. Być może przyjdzie kolega i powie, że tam nie ma hermetyzacji i polimorfizmu.

No być może przyjdzie i powie, być może będzie miał rację - tylko jaki to ma związek z moim pytaniem i Twoją tezą? Gdzie konkretnie znajduje się "ograniczenie dowolności"?
Albo idąc dalej - czym jest ta "dowolność" i co właściwie daje?

Właściwie jest tylko umową, że jeśli będziemy pisać w określony sposób, to wszystko będzie dobrze działać i w ogóle będzie tęczu.

A to z kolei, to kto stwierdził?

Pewnie autor pojęcia OOP. Nikt nie mówi, że trzeba pisać określony kod w określonej strukturze, bo inaczej umrzemy.

W takim razie poproszę o konkretny cytat konkretnej osoby.

nullpt4 napisał(a):

problemów które występują tylko w OOP :P

Niby masz rację, tylko ona nie prowadzi do wniosków, które chciałbyś ironicznie wyciągnąć.
Jeśli masz swój dom, to też musisz rozwiązywać problemy (przegląd kominów, czyszczenie rynien, koszenie trawników), których nie masz mieszkając pod mostem. Czy lepiej wybrać most?

W programowaniu proceduralnym trudno o wzorce projektowe, bo nie ma niczego, co można by projektować ani składać ze sobą na różne sposoby. Stosowanie obiektów rodzi potrzebę ich organizacji, a wzorce projektowe służą właśnie temu celowi. A problemy nie wynikają z OOP per se (bo istnienie paradygmatu nie tworzy problemów), tylko z zadań, które są pochodną wymagań.

. jasne, tylko o ten kod ludzie dbali, był nawet osobny zespół który analizował np. zależności między klasami i starał się jakoś to uprościć posługując się min wzorcami projektowymi.

To tak jakby jedna ekipa budowlana stawiała ściany krzywo, a druga potem popychała je patykami próbując wypionować pod wpływem lektury książki o poziomicach. Nie umiem sobie wyobrazić jakim cudem miałoby to zadziałać.

Ale zawsze jest szansa że pisali go sami debile włącznie ze mną :)

Debilizm oznacza lekkie upośledzenie umysłowe. Dość niefortunne określenie sytuacji, w której jedni ludzie klepią cokolwiek, a potem drudzy próbują to przerobić na kod. To jest po prostu zwykły nonsens.

To tak nie działa, że można sobie najpierw coś zwymiotować na klawiaturę, a potem to przerobić zgodnie z wzorcami i SOLID. Nie da się napisać idiomatycznie w OOP niczego sensownego (realizującego cel domenowy, nie hello worlda z kotkami i pieskami dziedziczącymi po sobie) nie stosując SOLID ani wzorców, bo albo wyjdzie z tego programowanie proceduralne (być może nawet na globalnym stanie) albo copy-paste. Więc albo pisze się od razu dobrze (i ma się OOP), albo ma się procedury w języku z klasami upstrzone dodatkowo losowymi elementami OOP, które jednak wcale związku z tym paradygmatem nie mają.

chodzi mi o wyrażanie abstrakcji korzystając z darów OOP, które w pewnym momencie prowadzi do ślepych uliczek i zagmatwania kodu.

Jeśli napisze się w sposób zagmatwany (np. stosując wszędzie interfejsy i fabryki, bo gdzieś się wyczytało, że na tym polega OOP), to będzie zagmatwane. Ale to nie jest efekt prawidłowego użycia OOP w miejscu jego zasadnego użycia.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-07-31 06:56
0
somekind napisał(a):

Jeśli masz swój dom, to też musisz rozwiązywać problemy (przegląd kominów, czyszczenie rynien, koszenie trawników), których nie masz mieszkając pod mostem. Czy lepiej wybrać most?

Oczywiście, że nie.
OOP jest domem, a wszystko inne mostem? :P

W programowaniu proceduralnym trudno o wzorce projektowe, bo nie ma niczego, co można by projektować ani składać ze sobą na różne sposoby.

bo nie ma niczego,co można by projektować Nie ma tego całego cyrku który rodzi problemy, Tak samo jest w FP, ale to nie przeszkadza w projektowaniu i składaniu, tylko pomaga. Po porażce współczesnego OOP zacząłem się interesować innymi paradygmatami i wykorzystywać w praktyce. Nie wiem jak będzie na dłuższą metę, ale jak na razie widzę kolosalną różnicę, na plus oczywiście. Podoba mi się też OOP w wydaniu twórcy tego paradygmatu.

Stosowanie obiektów rodzi potrzebę ich organizacji, a wzorce projektowe służą właśnie temu celowi. A problemy nie wynikają z OOP per se (bo istnienie paradygmatu nie tworzy problemów), tylko z zadań, które są pochodną wymagań.

W OOP są problemy np. z organizacją obiektów, a wzorce projektowe te problemy starają się rozwiązać. Nie ma ich w innych paradygmatach, tzn te wzorce przydają się do problemów które występują tylko w OOP, więc OOP jest pośrednią/bezpośrednią przyczyną tych problemów.

To tak jakby jedna ekipa budowlana stawiała ściany krzywo, a druga potem popychała je patykami próbując wypionować pod wpływem lektury książki o poziomicach. Nie umiem sobie wyobrazić jakim cudem miałoby to zadziałać.

Nie pracowali nad tym studenci po tutorialu o OOP, tylko bardzo doświadczeni ludzie. Kod może być dobrze napisany, ale przychodzą nowe wymagania, przez które dochodzą nowe zależności pomiędzy obiektami, których wcześniej nie musiało być, dlatego byli ludzie którzy nad myśleli (rozmawiając też z zespołami ofc) jak to wszystko przeorganizować żeby nie było spagetti.

której jedni ludzie klepią cokolwiek, a potem drudzy próbują to przerobić na kod. To jest po prostu zwykły nonsens.

ehhh, klepanie czegokolwiek ... . OOP jest genialne i bez skazy tylko ludzie to ch***

To tak nie działa, że można sobie najpierw coś zwymiotować na klawiaturę, a potem to przerobić zgodnie z wzorcami i SOLID.

Jasne, że nie. Kto mówił o zwymiotowaniu na klawiaturę i przerabianiu na SOID'a? chodzi mi o wyrażanie abstrakcji korzystając z darów OOP, które w pewnym momencie prowadzi do ślepych uliczek i zagmatwania kodu. Z pomocą przychodzi SOLID, wzorce projektowe i cała reszta, zaczyna to lepiej wyglądać, Nie mówiłem tutaj o projekcie, tylko bardziej ogólnie, gdzie końcówkę zadania ale po jakimś czasie developmentu problem powracał, a dobre praktyki i GoF przestawały pomagać doświadczyłem w projekcie w którym pracowałem. Tzn było OOP, którego nie wymyślali ludzie którzy dopiero co przeczytali tutorial o wzorcach. Projekt wyglądał ok, ale przychodziły nowe wymagania, które dodawały np zależności między obiektami których(zależności) wcześniej nie było, i mądrzy goście się zastanawiali jak to ogarnąć, ale po kilku udanych próbach, implementacja kolejnych funkcjonalności które wymagały dodania interakcji między obiektami, gdzie ich wcześniej nie było, stała się bardzo trudna. Oczywiście projekt ma ponad 10 lat.

(np. stosując wszędzie interfejsy i fabryki, bo gdzieś się wyczytało, że na tym polega OOP), to będzie zagmatwane. Ale to nie jest efekt prawidłowego użycia OOP w miejscu jego zasadnego użycia.

Oczywiście, że tak, ale kto tak robi? OOP ma problemy, na które odpowiedzią są np wzorce projektowe, ale niestety one też mają swoje granice.

edytowany 9x, ostatnio: nullpt4, 2019-07-31 14:25

Pozostało 580 znaków

2019-07-31 07:14
2
nullpt4 napisał(a):

Stosowanie obiektów rodzi potrzebę ich organizacji, a wzorce projektowe służą właśnie temu celowi. A problemy nie wynikają z OOP per se (bo istnienie paradygmatu nie tworzy problemów), tylko z zadań, które są pochodną wymagań.

W OOP są problemy np. z organizacją obiektów, a wzorce projektowe te problemy starają się rozwiązać. Nie ma ich w innych paradygmatach, tzn te wzorce przydają się do problemów które występują tylko w OOP, więc OOP jest pośrednią/bezpośrednią przyczyną tych problemów.

WTF?! Chętnie usłyszę, jakie są problemy w OOP które nie występują w innych paradygmatach, Wzorce rozwiązuję problemy, ale jako zagadnienia, a nie coś co sprawia trudność/kłopoty i to w taki sposób, by było to reużywalne i zrozumiałe przez innych. No sorry, ale niby w programowaniu funkcyjnym, czy proceduralnym nie ma zagadnień tworzenie struktur kodu implementujących wzory Obserwatora, Strategii, Fasady, Pyłku?

Programowanie obiektowe nie jest żadnym złem, de facto większość ludzi na świecie stara się programować obiektowo i większość kodu jest napisanych obiektowo (mimo, że w językach nie wspierających tego). Nawet Linux oraz Windows jest napisany w paradygmacie OOP.

Negowanie OOP to tak jakby odmrozić sobie uszy na złość mamie... To, że część osób nie rozumie niektórych mechanizmów OOP, a inne są szkodliwe(przez kiepskie zrozumienie ich większości np. dziedziczenie wielobazowe), nie oznacza, że cały OOP jest do bani...

Ostatnio mam wrażenie, że forum zalewa fala osób, względnie młodych co czegoś tam się nauczyli i wydaje im sie, że sporo wiedzą i posiedli mityczną prawdę...

Pokaż pozostałe 4 komentarze
Linuks jest kodem proceduralnym. Istnieją oczywiście pewne fragmenty, które mogą się ludziom kojarzyć z OOP, bo OOP jest w modzie, ale kernel nie jest "zorientowany obiektowo", a jedynie w niektórych miejscach wykorzystuje struktury ze zbiorem callback-ów - używa ich jednak możliwie rzadko, a nie możliwie często, bo jest - że tak to określę - "zorientowany proceduralnie" a nie obiektowo. - Troll anty OOP 2019-07-31 10:58
"Ostatnio mam wrażenie, że forum zalewa fala osób, względnie młodych co czegoś tam się nauczyli i wydaje im sie, że sporo wiedzą i posiedli mityczną prawdę" - myślę, że w ogóle na forach jest przewaga osób względnie młodych, oraz bez sensu byłoby się wypowiadać, gdyby się komuś wydawało, że na dany temat nic nie wie. Jednak jeśli chodzi o OOP, to moje obserwacje są takie, że praktycznie nie ma przeciwników OOP wśród osób zaczynających karierę. Przeciwnicy zaczynają się pojawiać dopiero po jakimś okresie pracy. - Troll anty OOP 2019-07-31 11:22
To zależy co rozumiemy przez zaczynające karierę. Nie ma przeciwników bo jeszcze nie wiedzą czy to dobre czy złe, ale z czasem poznają inne rzeczy, a często spotykają się z gównianym kodem OOP bo jest OOP popularne. Zaczynają się wypowiadać często nie mając na karku kilku lat np. tworzenia dużych systemów proceduralnie lub funkcyjnie więc ta ich wiedza się troszkę wirtualna. Oczywiście zgodzę się, że w kodzie OOP jest dużo WTF ale to tak jak z wirusami i Windowsem - jest sporo bo dużo ludzi używa. - somedev 2019-07-31 11:25
A darklang od Google jest bardziej funkcyjny? https://darklang.com/ - sanny 2019-07-31 16:40
Dark nie jest od google -.- dart - stivens 2019-08-10 09:19

Pozostało 580 znaków

2019-07-31 18:34
6
nullpt4 napisał(a):

OOP jest domem, a wszystko inne mostem? :P

Nie zrozumiałeś analogii. Nie chodziło o to, co jest czym, ale o to, że coś co daje większe możliwości wymaga też większych umiejętności obsługi.

Ale jesli chcesz stosować takie metafory, to w takim razie programowanie proceduralne jest takim szałasem/lepianką. W odpowiednim warunkach i skali zadziała, ale jeśli chcesz, aby na jednym hektarze mieszkało 5 tys ludzi z dostępem do wody i ciepła, to raczej się nie uda.

Nie ma tego całego cyrku który rodzi problemy,

Ale tak konkretnie, to czym jest ten cyrk, który rodzi problemy? Bo cały czas czytam, jak to wszystko jest złe, ale żaden konkret jeszcze nie padł.

Nie pracowali nad tym studenci po tutorialu o OOP, tylko bardzo doświadczeni ludzie.

No chyba jednak nie bardzo, o czym świadczy dalsza część historii. Chyba, że za doświadczenie uznajesz niesłusznie staż pacy. Tego można mieć nawet tysiąc lat i nadal nie rozumieć, o co chodzi. Spotkalem dziesiątki takich osób.

Kod może być dobrze napisany, ale przychodzą nowe wymagania, przez które dochodzą nowe zależności pomiędzy obiektami, których wcześniej nie musiało być, dlatego byli ludzie którzy nad myśleli (rozmawiając też z zespołami ofc) jak to wszystko przeorganizować żeby nie było spagetti.

Nie, nie może być dobrze napisany w takiej sytuacji. Jeśli na skutek nowych wymagań zmienia się istniejący kod, to znaczy, że łamie się SOLID, konkretnie OCP oraz najprawdopodobniej SRP. Gdyby ze zrozumieniem użyto wzorców projektowych, to problemy by nie występowały.
A jeśli ktoś nie przewidział, że wymagania się zmienią i nie zaprojektował struktury kodu tak, aby umożliwiała wprowadzanie zmian, to znaczy, że nie był za bardzo doświadczony.

Generalnie większość "problemów z kodem OOP" jakie widziałem w życiu (a widziałem bardzo dużo słabego kodu), wynikały z tego, że:

  1. Ktoś z całego OOP zrozumiał, że chodzi o dziedziczące po sobie klasy, więc tworzył bardzo skomplikowane hierarchie próbując umieścić w nich cały kod. Hierarchie te oczywiście szybko stawały się niemożliwe do utrzymania, a wprowadzanie zmian wymagało dodawania kolejnych drabinek if i is.
  2. Ktoś z całego OOP zrozumiał, że obiekt to połączenie danych i operacji na nich, tworzył więc wielkie obiekty, które wczytywały dane z dysku, zapisywały do bazy, wysyłały po sieci, itd.
  3. Ktoś programował proceduralnie z klasami - mając hierarchę danych do przetworzenia i procedury na nich operujące, które np. sprawdzają typ danych wejściowych, i w zależności od niego wykonują inną część kodu.
  4. Ktoś naczytał się o dobrych praktykach i próbował je wdrażać wszędzie, za to bezmyślnie i bezsensownie. Stąd się bierze jeden interfejs do każdej klasy, do tego jeszcze fabryka, wszystkie klasy rejestrowane w kontenerze IoC, brak static i mutowalnych struktur danych, które rzekomo są zakazane, itd., itp.
  5. Połączenie wszystkich powyższych.

Wszystko to wynika z niezrozumienia OOP, i braku stosowania SOLID oraz wzroców oraz tkwienia w proceduralnym myśleniu. Jedynie punkt czwarty wynika z jakiegoś sekciarstwa i nadmiernego stosowania wzorców, bo "takie są dobre praktyki", co również jest efektem ignorancji. Ale wszystko to jest efektem działań ludzi, a nie istnienia narzędzia.

Nie mówiłem tutaj o projekcie, tylko bardziej ogólnie, gdzie końcówkę zadania ale po jakimś czasie developmentu problem powracał, a dobre praktyki i GoF przestawały pomagać doświadczyłem w projekcie w którym pracowałem. Tzn było OOP, którego nie wymyślali ludzie którzy dopiero co przeczytali tutorial o wzorcach. Projekt wyglądał ok, ale przychodziły nowe wymagania, które dodawały np zależności między obiektami których nie było, i mądrzy goście się zastanawiali jak to ogarnąć, ale po kilku udanych próbach, implementacja kolejnych funkcjonalności które wymagały dodania interakcji między obiektami, gdzie ich wcześniej nie było, stała się bardzo trudna. Oczywiście projekt ma ponad 10 lat.

Zapewne przejście na programowanie proceduralne, wszystkie problemy rozwiąże. :)


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Gdyby ze zrozumieniem użyto wzorców projektowych, to problemy by nie występowały. xD Chyba, że za doświadczenie uznajesz niesłusznie staż pacy. Wszystko to wynika z niezrozumienia OOP, i braku stosowania SOLID oraz wzroców oraz tkwienia w proceduralnym myśleniu dobrze że wiesz lepiej jak było i kto na ile był kompetentny :P Wracam do moich nic nie umiejących kolegów, będziemy oglądać tutoriale z OOP :) - nullpt4 2019-07-31 18:43
@nullpt4: za hasłem "programowanie obiektowe" z Wikipedii: "Największym atutem programowania, projektowania oraz analizy obiektowej jest zgodność takiego podejścia z rzeczywistością – mózg ludzki jest w naturalny sposób najlepiej przystosowany do takiego podejścia przy przetwarzaniu informacji." - Nie wiem więc, czy tutoriale mają prawo tu pomóc, skoro przy pracy z paradygmatem obiektowym mózg ma pracować w sposób jak najbardziej naturalny, a nie wyuczony. - Troll anty OOP 2019-07-31 21:57

Pozostało 580 znaków

2019-07-31 21:00
1

OOP dzieli kod na logiczne bloki, którymi łatwo zarządzać, zwłaszcza w dużych projektach.
Dodatkowo mamy wzorce projektowe, które ułatwiają nam komunikacje z innymi programistami, powiesz nazwę wzorca projektowego i każdy ma już obraz o czym jest mowa. Większość problemów można sprowadzić do szeregu wzorców i tym samym stworzyć dobrą architekturę wzorców.
Problem w tym że wielu programistów nie wie do końca jak należy stosować wzorce, co prowadzi do tworzenia takich rzeczy:

data class Rectangle(val a :Int, val b) {
 ...
}

data class Square(a :Int) : Rectangle(a, a) {
 ...
}

albo

class BaseLogger {
    fun log(message : String) {
        ...
    }
}

class JakasKlasa : BaseLogger {
   ...
}

Pozostało 580 znaków

2019-08-02 14:37
3
somekind napisał(a):

Kod może być dobrze napisany, ale przychodzą nowe wymagania, przez które dochodzą nowe zależności pomiędzy obiektami, których wcześniej nie musiało być, dlatego byli ludzie którzy nad myśleli (rozmawiając też z zespołami ofc) jak to wszystko przeorganizować żeby nie było spagetti.

Nie, nie może być dobrze napisany w takiej sytuacji. Jeśli na skutek nowych wymagań zmienia się istniejący kod, to znaczy, że łamie się SOLID, konkretnie OCP oraz najprawdopodobniej SRP. Gdyby ze zrozumieniem użyto wzorców projektowych, to problemy by nie występowały.
A jeśli ktoś nie przewidział, że wymagania się zmienią i nie zaprojektował struktury kodu tak, aby umożliwiała wprowadzanie zmian, to znaczy, że nie był za bardzo doświadczony.

Nawet ludzie z ogromnym doświadczeniem niektórych zmian nie przewidzą. A z tych potencjalnych potrzeb, które przewidywali jako możliwe, tylko niewielka część rzeczywiście stanie się potrzebna, więc uwzględnianie ich wszystkich na samym początku stworzy tylko paraliż, przez który nigdy nie powstanie nawet prototyp. A nawet jakby było tak dużo czasu, że można by uwzględnić wszystkie potencjalne zmiany, które tworzącym przychodzą do głowy na początkowym etapie, to i tak objawi się nieunikniony problem: taka jest ludzka natura, że zazwyczaj nie wpada się od razu za pierwszym razem na rozwiązanie idealne. Zwykle potrzebny jest etap dochodzenia do rozwiązania metodą prób i błędów. Porównujesz dyskutanta i jego współpracowników z jakimś teoretycznym bytem nie popełniającym błędów i robiącym już za pierwszym razem idealnie - nie dziwne, że w takim porównaniu żyjący ludzie wypadają słabo.

Generalnie większość "problemów z kodem OOP" jakie widziałem w życiu (a widziałem bardzo dużo słabego kodu), wynikały z tego, że:
[...]

Streszczając to, co zastąpiłem przez "[...]": metoda dobra, tylko źle używana.
Jednak łatwość/trudność użycia narzędzia dobrze, oraz czy bardziej intuicyjne jest jego użycie dobre czy złe, też są ważnymi argumentami w ocenie jakości narzędzia. Z tego co piszesz, ludzie bardzo często używają OOP niepoprawnie. Czy więc rzeczywiście jest dobre, że ciągle brną w używanie czegoś, czego użycie im nie wychodzi?

Może odpowiedzią na rozpoczynające ten wątek pytanie powinno być:
"Jest bardzo prawdopodobne, że użyjesz OOP źle, nawet jeśli poświęcisz dużo czasu na jego naukę, więc lepiej zostań przy tym, co stosujesz obecnie." ?

edytowany 1x, ostatnio: Troll anty OOP, 2019-08-02 14:51

Pozostało 580 znaków

2019-08-02 21:58
4
Troll anty OOP napisał(a):

Może odpowiedzią na rozpoczynające ten wątek pytanie powinno być:
"Jest bardzo prawdopodobne, że użyjesz OOP źle, nawet jeśli poświęcisz dużo czasu na jego naukę, więc lepiej zostań przy tym, co stosujesz obecnie." ?

Można też rozwinąć tę tezę: jest bardzo prawdopodobne, że napiszesz dużo szajsowatego kodu, więc odpuść sobie kodowanie w ogóle.

Ja bym poszedł w drugą stronę: poznaj OOP, poznaj FP, poznaj różne języki, podejścia i narzędzia, by rozszerzyć horyzonty. Później będzie łatwiej ci ocenić co się w twoim przypadku sprawdza, a co nie. Ja tak zrobiłem i nie żałuję.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2019-08-03 13:06
0

W sumie jak by się głębiej zastanowić nad tematem, to największym plus OOP na innymi paradygmatami programowania to jest polimorfizm. Ogólnie jak dla mnie upychanie na siłę wszystkiego w klasach jest bezsensem. Już kiedyś poruszałem gdzieś ten temat, ale wtedy zwolennicy OOP mnie przekopali :D

Pozostało 580 znaków

2019-08-03 13:24
0

Polimorfizm możesz mieć i bez OOP. Dla przykładu w Ruście masz typeclassy pod nazwą traitów. Rustowe traity mogą mieć czasami hierarchie bardzo podobne do hierarchii obiektowych. Trait objects w Ruście natomiast pozwalają w pewnych przypadkach na OOPowy polimorfizm (OOPowego dziedziczenia jednak nadal nie ma) - w zasadzie można powiedzieć, że trait objects są OOPowym elementem Rusta.

Typeclasses są też w językach funkcyjnych, np Haskellu (od niego pochodzą). Mają swoje hierarchie i związane z tym problemy natury projektowej. Które metody mają mieć domyślne implementacje, a które mają być czysto abstrakcyjne? Jakie mają być zależności między typeclassami? Szereg problemów, które mają swoje analogie w OOPie.

Poza tym polimorfizm i tak wszyscy używają. Jak ktoś pisze w Pythonie i nie używa wprost dziedziczenia to i tak tworzy niejawne hierarchie klas, gdy np jedna zmienna w metodzie przyjmuje różne typy w zależności od tego co ją wywołuje. Makro w C czy szablon w C++ może operować na różnych typach danych - ważne jest tylko, by kod wypluty przez preprocesor się kompilował.

Ponadto OOPowy polimorfizm można zaimplementować i w czystym C. Wcześniej podałem prosty przykład z wrzucaniem wskaźników do funkcji od struktur z danymi. Bardziej skomplikowany pomysł na zaimplementowanie OOPa w czystym C to https://en.wikipedia.org/wiki/GObject - GObject jest podstawą GTK+ i GNOME. Jak widać w GNOME nawet się nie czają i nie udają, że nie używają OOPa - nazwali swoją abstrakcję wprost obiektem.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 5x, ostatnio: Wibowit, 2019-08-03 13:56
Ale nie każdemu podchodzi programowanie obiektowe, ale odnajdzie się w programowaniu funkcyjnym czy proceduralnym. Rust nie jest obiektowy, to programista Javy przyzwyczajony do OOP próbuje tak pisać w Ruscie. - sanny 2019-08-10 20:05
Nie każdy programista Javy pisze w idiomatycznym OOPie. Idiomatycznego OOPu uczy np DDD, a ile programistów go stosuje? Stawiam, że jest masa programistów piszących osobno klasy pełne getterów i setterów oraz klasy serwisowe, które mielą te klasy bez logiki. Można sobie filozofować, ale faktem jest iż OOP istnieje nawet w czystym C i jakoś nie ma ideologicznego pędu na unikanie go za wszelką cenę. Nikt nie pokazał tutaj też, że np programowanie funkcyjne jest łatwiejsze niż OOP. Niech ktoś rzuci kodem w Haskellu. - Wibowit 2019-08-10 20:12
Skoro piszesz że programiści Gnome/GTK stosują klasy w C, to czemu nie wpadli na genialny pomysł przy tworzeniu Gnome3/GTK i nie wybrali C++? Skoro i tak przepisywali to środowisko graficzne od zera i tworzyli nową bibliotekę graficzną GTK3. Objective-C miał być C z klasami i kiepsko to wyszło. - sanny 2019-08-10 21:26
Nie wiem. Stawiam, że to po to by lepiej integrować się z innymi językami. C ABI jest obsługiwane przez masę platform programistycznych. C++ ABI jest obsługiwane tylko przez C++. Microsoft też stworzył przenośną obiektówkę dostępną z poziomu wielu platform, także czystego C: https://en.wikipedia.org/wiki/Component_Object_Model https://www.codeproject.com/Articles/13601/COM-in-plain-C - Wibowit 2019-08-10 21:36
Trochę przesadziłem z tym C i Gnome3, teraz dominuje tam JavaScript. Jedynie Xfce4 to w większości C. - sanny 2019-08-10 21:38

Pozostało 580 znaków

2019-08-03 13:50
0
Wibowit napisał(a):

Polimorfizm możesz mieć i bez OOP.

Całkiem możliwe, a nawet pewnie tak jest jak piszesz. W sumie moja odpowiedź była w kontekście świata w jakim ja się kręcę, dlatego jak ktoś ma szersze horyzonty to może być niepoprawna lub wręcz rażąca w oczy :)

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0