Vlákno názorů k článku
Kritika objektového programování: je to katastrofa? od s - Chce se psat list.inset(item) nebo list_insert(list, item)? OOP...

Chce se psat list.inset(item) nebo list_insert(list, item)? OOP je jen syntakticky cukr. I Linus pise objektove, jen si oblibul zapis cislo dva. Z nejakeho duvodu pak vznikly jazyky, ktere si to vynucuji a vynucuji si nejen OOP, ale treba i indentaci. Takove jazyky nemam rad a dost dobre nechapu, ze se tak rozsirily.

Teraz ste uplne presne trafil. STRUCT a CLASS maju k sebe velmi blizko. Iba v tom CLASS mam 'this' context, mam preciznejsiu moznost volby pristupnosti fieldov (public, private, ...) a funkcie sa mi nepovaluju niekde v sklade dalsich 1000 funkcii ale mam ich tam pekne pokope. Neviem si predstavit ze by niekto extrahoval vsetky funkcie java runtime bez dalsich kniznic ako by som tam hladal to co prave potrebujem.
No a potom su tam dalsie koncepty ktore su uz pre niekoho absolutne neuchopitelne ako dedicnost a polyformizmus a ... co su iba dalsie nastroje v tvojom toolboxe ktore pri spravnom pouziti prinasaju vyhody.

Problém je, že "OOP fanoušci" si vůbec neuvědomují, že nástroje, které jim jejich "paradigma" nebo jazyk poskytují, jsou k dispozici i jinde a často možná i v lepší podobě:

1. Organizace funkcí do jednoho "kontaineru" - moduly, namespacy

2. Zapouzdření dat - opět moduly s exportem konstruktorů, ale bez přímého přístupu k datům pro funkce mimo modul

3. Polymorfismus naprosto není výsadou OOP, v FP apod. typově bohatých jazycích je to triviální

4. Dědičnost je dost sporná (vzpomínám si na zdejší diskusi, zda čtverec je potomek obdélníka nebo naopak), ale pokud jde o sdílení implementace, v jiných jazycích se používají třeba traity.

Takže ano, nástroje - OOP jako nástroj, FP jako nástroj, procedurální programovací techniky jako nástroj - jasně. Ale donedávna se OOP používalo jako dogma a všelék, přičemž jeho konkrétní implementace často přináší spoustu problémů a hází programátorům klacky pod nohy namísto pomoci.

23. 7. 2019, 14:04 editováno autorem komentáře

Ale problem je ze ja a mnoho ludi a firiem je s objektovym programovanim spokojnych a stastnych. Dokazu na tom vytvorit funkcne riesenia ktore drzia svet nad vodou. Neviem preco sa teraz snazi niekto prist a kopat do toho ze je to zle. Piste si v LISPe mne je to jedno. Potom pridte a ukazte nam ako ste to super napisali, bolo treba iba 1/3 kodu a zerie to iba 1/2 RAM a 2/3 procesora oproti rieseniu v Jave. OK. Dovtedy je to iba stekanie psov, karavana MUSI ist dalej.

Myslím, že v dnešní době představitelem hardcore FP není Lisp, ale spíš třeba ten Haskell. "Problémy", které vedou ke kritice OOP jsou jiné:

1. Jak jsem se snažil ukázat, výhody, které OOP nabízejí, neplynou nutně z objektovosti, ale objekty jsou jednou z možností, jak jich dosáhnout. Objektová slepota, kterou způsobilo protežování OOP paradigmatu v posledních dvou desetiletích, zabraňuje dalšímu vzdělávání lidí v oboru.

2. OOP přináší i nevýhody, spousta věcí se dá mnohem elegantněji realizovat pomocí technik vycházejících z FP.

Budoucnost je "postobjektová", "postprocedurální" a "postfunkcionální", i ta vaše Java už je dávno hybridní, zavádí lambdy atd. Za kritiku buď rád, pomáhá všem. Vůbec nemám nic proti používání Smalltalku objektovými nadšenci a Haskellu FP nadšenci, ale bylo by dobré, kdyby znali dobře i jiná paradigmata a věděli, oč svou volbou přicházejí. Většina z nás ale bude používat jazyky, které nejsou takto explicitně vyhraněné a tudíž ten rozhled a nadhled je nutný k tomu, abychom využili současné hybridní programovací nástroje naplno.

Zrovna o kus výše jsem psal, proč dictionary nemůže fungovat jako objekt. Zkuste si to přečíst.

Dědičnost a polymorfismus v linuxovém kernelu? I tyhle věci, základní kameny C++, se v Cčku dají aproximovat (a v kernelu se to používá) - spousta structů, které obsahují téměř jenom pointery na funkce. Takový struct je pro mě abstraktní třída. Polymorfismus datových memberů se dá realizovat konstrukcí "union" nebo kompozicí structů, v nejhorším případě void* odkazem na další privátní data.

Ohledně opouzdření vnitřní logiky, aby některé třídy či jednotlivé member proměnné a metody mohly zůstat "private"... k tomu přece slouží rozdělení zdrojáků do většího počtu drobných "translation units" = do jednotlivých Céčkových souborů (a obvykle k nim přináležejících .H). Céčkový sobor může deklarovat proměnné a funkce "static", takže se neobjeví v tabulce exportovaných symbolů = "nejsou vidět" z jiných translation units. A oddělený hlavičkový soubor bude obsahovat pouze zveřejněné vnější rozhraní. Ono i z hlediska čitelnosti a rozsahu kódu to vychází tak, že jedna "translation unit" (soubor .C) by měl pojednávat cca jednu větší "třídu objektu", nebo pár těsně spřízněných tří, které si mohou či musí vidět navzájem do talíře...

Tohle vše se v kernelu v Céčku samozřejmě používá. Není to tak elegantní jako vyšlapané pěšinky C++, ale přesto to funguje.

Přesně tak. Dám příklad driveru pro zvukovku s čipem ICE1724. Struct driveru definuje sadu metod (pointerů na funkci) s defaultní implementací. Každá zvukovka s tímto kontrolérem (je jich spoustu) bude mít základní funkcionalitu. A konkrétní zvukovka s přidanými funkcemi ve své "translation unit" "přetěžuje" některé z těchto metod svým kódem (dokonce i některé volají metodu "předka" a za to přidají svůj malý štěk). Zvukovka má svůj "odděděný" struct, ve kterém si přepíše příslušné pointery svými přetěžujícími metodami. A když přijde požadavek na novou zvukovku, jejíž jiná funkcionalita do stávajícího modelu nepasuje, buď si přepíše celou tu delší metodu i za cenu většího copy/paste, nebo se ukáže, že základní sada metod není dostatečně obecná (např. princip práce s hodinami) a zrefaktoruje se to v základu na obecnou/konkrétní vrstvu.

Proč se zde snažíte o dědičnost a polymorfismus, když ani jedno není jádrem OOP? Dědičnost se tu již probírala a polymorfismus je JEN JEDNÍM důsledkem zasílání zpráv. Popsal jste tu jakési zapouzdření, ale jak požádáte ve vašem „objektu“ o spuštění „metody“, kterou nemá? Teprve až tohle pochopíte, pochopíte taky, proč struct nemůže být objektem.

Proč je tak důležité spuštění metody, kterou objekt nemá a jak by měl reagovat?

Jasně, názor můžeme mít všichni, ale jen podložený názor je skutečně hodnotný. Takže jej zkuste podložit a rozepsat, co se děje při jednotlivých verzích zpracování.

Když dojdeš k pozdní vazbě, tak ti dojde, že to není jen cukr.

I to je samozřejmě věc, kterou lze udělat i v klasickém C - a v jádře se to dělá každou chvíli. Jen je to v (např.) C++ o poznání pohodlnější a z určitého úhlu pohledu i přehlednější.

Super, nadhoďte.

Namátkou třeba netdev_ops, ethtool_ops, struktury reprezentující různé druhy socketů, zpracování síťových a transportních protokolů v receive path, celá koncepce VFS, ...