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.
Tak asi dělají to co je potřeba aniž by to muselo odpovídat knižním definicím ideálu nějakého konceptu ... jako třeba dřívější js, prostě se tím pomocí několika fukncí ve tvaru modulů oživil web a bylo hotovo, viz. např. jQuery, koho zajímalo co si o tom myslí akademická komise?
23. 7. 2019, 12:58 editováno autorem komentáře
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.
Takze sa zhodneme ze napriklad v Jave mam organizaciu kodu so striktnymi datovymi typmi, objektami, mozem robit jednoducho refactoring, nastroje my pomahaju doplnanim kodu ... . Vnutri metody mozem pouzit FP cez streams a closures.
Popri tom mam k dispozicii milion kniznic na riesenie veci ako persistencia objektov do DB, Inversion of Control frameworky, messaging, rule engine, standardne workflow nastroje (BPMN), Aspect Oriented Programming, ... . Takze preco mam akoze prechadzat na ten Hashell? Co by mi to malo priniest? Je kod lahsie citatelny? Je rychlejsi? Zozeniem lahsie programatorov? Ved na programovanie v JVM bezne pouzivam JS na dynamicke casti, rozne template engine (velocity, mustache, ...), BPML, ... ved ja poznam aj FP ale bohuzial nenasiel som na nom zatial ziadnu vyhodu preco by som si to mal tahat do projektov? Dokonca na nom vidim velke mnozstvo nevyhod a rizik ktore iba cakaju na objavenia. FP a jeho frameworky su v infatilnom stave v ktorom bola Java tak 15 rokov dozadu.
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.
Protože se tím mění mechanismus řízení běhu programu, kdy iniciátor operace již nemusí nic vědět o struktuře dotazované entity, což posunuje okamžik rozhodnutí na později, čímž zvyšuje zaměnitelnost oné cílové entity a tím obecnost či znovupoužitelnost (a tím jednoduchost) kódu. To(!) bylo cílem Kaye.
Jako nejjednodušší ukázku je možno si v různých jazycích zkusit vyrobit proxyobjekt.