Těžké OOP problémy

[Jiří Havel]

V podstatě to není zas tak těžký úkol ...

Mě to teda zní zatraceně komplikovaně. A ten zárodek je už v tom, že se tam ta funkcionalita přidává postupně a specifikace se mění pod rukama. Tohle se dříve či později bude muset překopat bez ohledu na paradigma.

Jiným příkladem může být například rozsáhlý systém, který staví model pro Marketing, Sales, Ordering a Support. Všechny tyto oddělení pracují se zákazníkem, ale není žádané, aby tato třída byla v systému pouze jednou, protože bude obsahovat příliš odlišnou funkcionalitu, bude mít příliš závislostí, bude mít tendenci růst apod.

Tady by mi osobně seděla varianta Entity-Component systému. Zákazník by měl v základu jen minimum dat a každé oddělení by si na něj mohlo přidávat komponenty s dodatečnými daty podle potřeby. Každé oddělení musí rozumět jen pár komponentám a zbytek neřeší. A o funkcionalitu se starají právě ta oddělení. Zákazník a jeho komponenty jsou jenom balíky dat.
ECS je oblíbený hlavně v gamedev světě. Není to klasické OOP, spíš to připomíná relační databáze. Ale je to zatraceně mocný a flexibilní přístup.

[Reklama]

[Mirek Prýmek]

ale celkový design je špatně

Posuzovano cim? Nejakou metodologii? Metrikou? Dojmem? Vkusem? Clovekohodinami venovanymi udrzbe?

ukázku toho něčeho, pro co je těžké navhrnout objektovou strukturu správně, a nebo jak se postupnými logickými kroky a přidáváním funkcionality, dostaneme někam, kam nechceme a podobně.

Cokoliv krome ucebnicovych prikladu.

ač třídy jakš-takš splňovali např. SOLID, tak tam vznikly vazby všechno se vším - zárodek Ball of mud.

To je prave ono.

[Mirek Prýmek]

neobsahuje data races, t.j. ze je data race free?

Ale tak to zase není limitováno na OOP, a setkáte se s tím i při programování např. v čistém C.  Naopak v C++ to mnohdy může být jednodušší kvůli věcem jako shared_ptr, které dělá reference counting za vás.  (Ale nejsem C++ programátor, tak netuším, jestli v tom není nějaká zrada...)

Pocitani referenci je ten nejmensi problem, relativne trivialne resitelny. Problem je v tom, ze (dnesni, takzvane) OOP uplne automaticky pocita s tim, ze objekt je entita a pritom klidne do te entity necha vlezt nekolik vlaken. Cista schizofrenie.

Ilustrace:

Ucebnicovy priklad:  zarovka.zhasni(); zarovka.rozsvit();

Realita: vlakno1.zhasni(zarovka) ...a zaroven klidne... vlakno2.rozvit(zarovka)

Ten, kdo v (dnesnim, takzvanem) OOP kona neni objekt, ale vlakno. I kdyz abstrakce se tvari jinak a timpadem i ucebnice tvrdi neco jineho.

[Mirek Prýmek]

Sorry, ale tohle si nemuzu odpustit...

třídy jakš-takš splňovali

jakŽ takŽ splňovalY

[Ink]

Nic take nejestvuje, kedze tu mame teoriu vypocitelnosti.
vsteko co vies namodelovat cez FP vies namodelovat aj cez OOP, su to len dva pohlady na to istu vec.

Zrovna tak lze vhodně upraveným kladivem utáhnout šroubek a šroubovákem zatlouct hřebík.

[Reklama]

[Idris]

neobsahuje data races, t.j. ze je data race free?

Ale tak to zase není limitováno na OOP, a setkáte se s tím i při programování např. v čistém C.  Naopak v C++ to mnohdy může být jednodušší kvůli věcem jako shared_ptr, které dělá reference counting za vás.  (Ale nejsem C++ programátor, tak netuším, jestli v tom není nějaká zrada...)

Pocitani referenci je ten nejmensi problem, relativne trivialne resitelny. Problem je v tom, ze (dnesni, takzvane) OOP uplne automaticky pocita s tim, ze objekt je entita a pritom klidne do te entity necha vlezt nekolik vlaken. Cista schizofrenie.

Ilustrace:

Ucebnicovy priklad:  zarovka.zhasni(); zarovka.rozsvit();

Realita: vlakno1.zhasni(zarovka) ...a zaroven klidne... vlakno2.rozvit(zarovka)

Ten, kdo v (dnesnim, takzvanem) OOP kona neni objekt, ale vlakno. I kdyz abstrakce se tvari jinak a timpadem i ucebnice tvrdi neco jineho.

Tohle je dost nicneříkající příklad, ale když už, tak ty dvě metody se syncnou na logice spínání relé.

[Kit]

Pocitani referenci je ten nejmensi problem, relativne trivialne resitelny. Problem je v tom, ze (dnesni, takzvane) OOP uplne automaticky pocita s tim, ze objekt je entita a pritom klidne do te entity necha vlezt nekolik vlaken. Cista schizofrenie.

Ilustrace:

Ucebnicovy priklad:  zarovka.zhasni(); zarovka.rozsvit();

Realita: vlakno1.zhasni(zarovka) ...a zaroven klidne... vlakno2.rozvit(zarovka)

Ten, kdo v (dnesnim, takzvanem) OOP kona neni objekt, ale vlakno. I kdyz abstrakce se tvari jinak a timpadem i ucebnice tvrdi neco jineho.

Tohle je dost nicneříkající příklad, ale když už, tak ty dvě metody se syncnou na logice spínání relé.

Řekl bych, že Mirek Prýmek na to kápl. Souběhy z více vláken dokáží nadělat v OOP pěknou paseku. Netvrdím, že to nejde vyřešit, ale triviální úloha to rozhodně není.

[Johnny]

Řekl bych, že Mirek Prýmek na to kápl. Souběhy z více vláken dokáží nadělat v OOP pěknou paseku. Netvrdím, že to nejde vyřešit, ale triviální úloha to rozhodně není.

A co třeba v Céčku? Tam ne?

[Mirek Prýmek]

Tohle je dost nicneříkající příklad

Už jsme tady o tom minimálně jednou sáhodlouze diskutovali, tak jsem se nechtěl moc opakovat.

Mentální/sématnický model OOP je "objektu posílám zprávu", v horším případě "na objektu volám metodu". A učebnice mi řekne "na objektu žárovka vyvolám akci". To ale vůbec neodpovídá realitě. V realitě tu akci dělá vlákno. Objekt žárovka mu jenom dodá popis, jak tu akci udělat. A ochotně ji dodá libovolnému vláknu, klidně i několika zaráz. 

Takže to není "vyzývám objekt k akci" ( žárovka.rosviť() ), ale "vyzývám vlákno k akci a dávám mu k dispozici funkci a data" ( vlákno.rozsviť(žárovka) ).

Je to naprosto matoucí a škodlivé schovávání jednoho konceptu za druhý. Škodlivé proto, že to opravdu vypadá podobně. Ale právě jenom dokud máme jedno vlákno. Jakmile jich máme víc, začnou se dít divy.

, ale když už, tak ty dvě metody se syncnou na logice spínání relé.

Mylně se domníváš, že tam je atomicky spínající relé. Ve skutečnosti je tam žhavení, které je potřeba spustit pět minut před vlastním rozsvícením. Druhé vlákno zapne žhavení už rozsvícené žárovky, což způsobí destrukci celého nám známého vesmíru.

[Mirek Prýmek]

A co třeba v Céčku? Tam ne?

Céčko má jeden zásadní rozdíl: netváří se, že je něčím, čím není. V céčku předávám funkcím data. Jestliže spustím zaráz dvě funkce nad stejnými daty, nad kterými by zaráz spuštěny být neměly, dojde samozřejmě k chybě. Protože jsem jako programátor udělal chybu. Ne proto, že mi koncept tvrdil něco, co v reálu není pravda.

[Idris]

A co třeba v Céčku? Tam ne?

Céčko má jeden zásadní rozdíl: netváří se, že je něčím, čím není. V céčku předávám funkcím data. Jestliže spustím zaráz dvě funkce nad stejnými daty, nad kterými by zaráz spuštěny být neměly, dojde samozřejmě k chybě. Protože jsem jako programátor udělal chybu. Ne proto, že mi koncept tvrdil něco, co v reálu není pravda.

Moc to OOP prožíváš Normální vývojář se neřídí tím, co mu řekne “koncept,” ale jednoduchými instrukcemi, jak na synchronizaci. Tím nikdo netvrdí, že nějaká tupá PHP lopata to zvoře, ale ty můžeme ignorovat.

[Mirek Prýmek]

Normální vývojář se neřídí tím, co mu řekne “koncept,”

Po dlouhé době s tebou velmi zásadně nesouhasím. OOP naučí lidi nějak myslet. V pojmech "mám žárovku", "řeknu žárovce, aby se rozsvítila". Což je naprosto perfektně OOP a nemám proti tomu nic. Až na to, že implementace dělá něco úplně jiného, v tom je problém

ale jednoduchými instrukcemi, jak na synchronizaci.

Synchronizace je (v tomhle kontextu) jenom narovnávák na ohýbák. V OOP nemá co dělat. Já mám prostě žárovku a řeknu jí, aby se rozsvítila. Jestliže se právě nažhavuje, má mi odpovědět "sorry, teď nemůžu, mám na práci něco jinýho". Synchronizace má svoje místo mezi entitami (já začnu až ty skončíš), nemá být zneužívaná k tomu, abych "zesynchronizoval" "jednu entitu". Už v kombinaci těhle dvou pojmů je vidět, jak je to ujetý. Co se tam totiž synchronizuje? Vlákna. A proč? No protože vlákna jsou tam ty entity, ne objekty Protože chci dosáhnout "prvně já (vlákno1) rožnu a pak ty (vlákno2) zhasneš". Objekt tam žádnou entitou není. Jenom se snaží udělat takovej dojem. A ochotně mu to žereme. Dokud máme jenom jedno vlákno

[Johnny]

OOP naučí lidi nějak myslet. V pojmech "mám žárovku", "řeknu žárovce, aby se rozsvítila". Což je naprosto perfektně OOP a nemám proti tomu nic. Až na to, že implementace dělá něco úplně jiného, v tom je problém

Já tuhle logiku moc nechápu, 1) koncept něco tvrdí (údajně), ale chyba v je konceptu, ne v programátorovi, který se tím slepě řídí/neřídí, 2) koncept lidi nějak naučí, a zase je chyba v něm, ne v lidech...
Koncept podle mě sám nic netvrdí, zase jsou to jenom lidi, jedni mají pravdu, druzí ne. Koncept je OK.

Vidím ale jednu věc, na které se snad shodneme, to že OOP něco lidi naučí, ale implementace dělá něco jiného, je chyba. To beru. Ale tady je to chyba té implementace, ne toho konceptu. Podle mě nebyl původní dotaz na konkrétní implementace OOP ale obecně...

[Idris]

Normální vývojář se neřídí tím, co mu řekne “koncept,”

Po dlouhé době s tebou velmi zásadně nesouhasím. OOP naučí lidi nějak myslet. V pojmech "mám žárovku", "řeknu žárovce, aby se rozsvítila". Což je naprosto perfektně OOP a nemám proti tomu nic. Až na to, že implementace dělá něco úplně jiného, v tom je problém

ale jednoduchými instrukcemi, jak na synchronizaci.

Synchronizace je (v tomhle kontextu) jenom narovnávák na ohýbák. V OOP nemá co dělat. Já mám prostě žárovku a řeknu jí, aby se rozsvítila. Jestliže se právě nažhavuje, má mi odpovědět "sorry, teď nemůžu, mám na práci něco jinýho". Synchronizace má svoje místo mezi entitami (já začnu až ty skončíš), nemá být zneužívaná k tomu, abych "zesynchronizoval" "jednu entitu". Už v kombinaci těhle dvou pojmů je vidět, jak je to ujetý. Co se tam totiž synchronizuje? Vlákna. A proč? No protože vlákna jsou tam ty entity, ne objekty Protože chci dosáhnout "prvně já (vlákno1) rožnu a pak ty (vlákno2) zhasneš". Objekt tam žádnou entitou není. Jenom se snaží udělat takovej dojem. A ochotně mu to žereme. Dokud máme jenom jedno vlákno

Já bych to fakt tak nedramatizoval. Jak sám píšeš, žárovka má sama rozhodnout a případně volajícího poslat někam (žárovka je v tomto ohledu agent), pokud to nedělá, je špatně její kód. Nemá smysl se rozčilovat, když někdo mizerně napíše objekt nebo knihovnu.

Že OOP naučí nějak myslet bych taky nepřeceňoval, “nějak myslet” naučí matematika nebo třeba analytická filosofie, ale to už se bavíme na úplně jiné úrovni, běžný Ferda programátor je rád, když mu stačí myslet ve for cyklech.

[Idris]

OOP naučí lidi nějak myslet. V pojmech "mám žárovku", "řeknu žárovce, aby se rozsvítila". Což je naprosto perfektně OOP a nemám proti tomu nic. Až na to, že implementace dělá něco úplně jiného, v tom je problém

Já tuhle logiku moc nechápu, 1) koncept něco tvrdí (údajně), ale chyba v je konceptu, ne v programátorovi, který se tím slepě řídí/neřídí, 2) koncept lidi nějak naučí, a zase je chyba v něm, ne v lidech...
Koncept podle mě sám nic netvrdí, zase jsou to jenom lidi, jedni mají pravdu, druzí ne. Koncept je OK.

Vidím ale jednu věc, na které se snad shodneme, to že OOP něco lidi naučí, ale implementace dělá něco jiného, je chyba. To beru. Ale tady je to chyba té implementace, ne toho konceptu. Podle mě nebyl původní dotaz na konkrétní implementace OOP ale obecně...

Tady je vidět, proč “all evidence points to OOP being bullshit.” Naprostá většina algoritmů je čitelnější ve strukturovaném paradigmatu.