Těžké OOP problémy

[Mirek Prýmek]

Není to přesně naopak, minimálně v anglické gramatice?

No vidis, vlastne je. Nejenom v anglictine, ale i ve filosofii. To jsem se teda dobre upsal )) Diky.

[Reklama]

[Kit]

Pokud objekt má atributy, ale nemá chování, je  anemický. Může jím být třeba ta žárovka, která reaguje na vypínač. Teprve vnitřní chování z něj činí objekt ve smyslu OOP, který může (nemusí) nejen reagovat na povel (zprávu) "lehni", ale i na událost "přišel cizinec".

BTW: Ta lingvistika nám to pěkně zamíchala.

[Idris]

V OOP má každá metoda přístup ke všem datům objektu a objekty obsahují bambiliony referencí, takže granularita zamykání je problém. V praxi se to pak často řeší způsobem "GUI vlákno + výpočetní vlákno/vlákna", protože kdybys to měl řešit na úrovni metod, tak by ses z toho zvencnul, nasekal tam spoustu chyb a ještě by to bylo nečitelné.

GUI je dost specifický případ, tam je jeden kontext (hierarchie UI objektů), do které sahá kupa objektů. Jinak by si ale měl synchronizace řešit každý objekt sám vnitřně. Kdysi jsem třeba dělal na SW pro roboty (automatické vozíky ve skladech apod.), tam dochází ke zpožděním (senzor-zpracování-aktuátor), mnohé AI algoritmy jsou NP úplné apod., ale stejně to jde řešit elegantně přes OOP. Jen je třeba vědět jak.

[Idris]

na nějaké koncepty a SW inženýrství zvysoka šitujou a i tak píšou o řády lepší kód než někdo, kdo někde na VŠE “studoval koncepty”

Já tvrdím, že OOP koncepty lidem matou hlavy. Tahle tvoje historka je s tím tvrzením ortogonální

Ani ne. Jen tvrdím, že když má někdo PhD z astrofyziky, nějaký zcestný koncept ho nezmate, protože automaticky (podvědomě) ho bude ignorovat jako blbost. Ta laťka může být jinde, pro mnoho lidí je matoucím konceptem i for cyklus (bohužel i pro mnoho wannabe vývojářů). Když je někdo slabomyslný, mate mu hlavu OOP koncept stejně jako Okamura z SPD, dementní alkoholik na Hradě etc., to není vina OOP, ale onoho individua.

[Idris]

Nechapu blaboleni, proc by jako zarovka mela sama něco delat

To je v pohodě, rozhodně nejsi sám.

muj svet je ale objektovy.

Však to je v pohodě. Když tě to baví psát a někdo ti za to zaplatí, není nikde žádný problém. Jsou i lidi, kteří píší ve Visual Basicu a baví je to. Rozhodně nemám potřebu kohokoli o čemkoli přesvědčovat.

Visual Basic není tak špatný, byly doby, kdy si jeho kritikou studenti IT v prváku na VŠE potlačovali komplex méněcennosti, ale měl jsem za to, že z toho už puberťáci vyrostli.

[Reklama]

[Jiří Havel]

P.S. "normálně" neříkáme "objekt" skoro ničemu. Možná tak ještě budově nebo souboru budov Ten náš "objekt" je celkem čistý kalk z angličtiny.

Pravda. Asi jak už občas přemýšlím napůl v angličtině, tak mi to automaticky splynulo s předmětem.

Jinak by si ale měl synchronizace řešit každý objekt sám vnitřně.

To funguje fajn do doby než chci poslat několik zpráv po sobě. Uvažovat stylem že o objektu nevím vůbec nic i když mi právě nějak odpověděl na zprávu není moc intuitivní a ani praktické.

[Idris]

Mimochodem, když už jsme u té amatérské lingvistiky, tak ve filosofii se "objekt" odlišuje od "subjektu" právě tím, že je aktérem, původcem děje. A proto má i ta žárovka konat autonomně. Kdyby byla pasivní, nebyla by "objektem", ale "subjektem"

Tos těžce netrefil, subjekt/objekt jsou pojmy z oblasti syntaxe, kdežto původce děje (aktor, česky konatel) je sémantický pojem. Gramatický subjekt nemusí být konatelem a objekt jím být může, je to na sobě naprosto nezávislé. Viz například Panevová: Formy a funkce ve stavbě české věty (doufám, že si ten název pamatuju správně, tohle jsem četl někdy přes 20 lety), tohle je geniální knížka se spoustou (českých) příkladů z pomezí syntaxe, sémantiky a pragmatiky.

[Idris]

Není to přesně naopak, minimálně v anglické gramatice?

Chybička se stane, chtěl to napsat naopak, ale ani tak to neplatí.

[Standa Blábol]

OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.
Zkousel jsem to dneska rano v koupelne, byl jsem tam ja, zena a deti a normalne to fungovalo, zarovka svitila presne podle pozadavku.

Jistě to skvěle funguje i v případě, že ty a manželka chcete mít rozsvíceno, ale děti chtějí mít zhasnuto. Ve chvíli, kdy je objektů Osoba víc, musíš zajistit (ne)svícení buď fackováním, tedy soutěží mezi objekty Osoba, anebo technicky, kdy k žárovce je přidán doplněk, který nedovolí změnu stavu častěji, než např. jednou za minutu.

OMG, pokud chci resit problem prioritizaci pristupu jednotlivych Osob k Zarovce, tak budu resit prioritizaci, s vlastni Zarovkou to nema nic spolecneho. To je tupe zarizeni, ktere sviti, kdyz do nej tece proud a nesviti, kdyz ne.
Alespon v mem svete to tak je.
Opravdu netusim, proc by proboha zarovka mela resit, jestli ji nekdo nezapina moc casto...

Pro reseni tohoto pozadavku zkratka pred zarovku predradim autorizacni ci jinou proxy, v pripade moji koupelny to budu ja, vystarano.

Rad bych videl architektonicke vytvory mistniho osazenstva, to musi byt veru zajimave cteni...

[Kit]

OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.
Zkousel jsem to dneska rano v koupelne, byl jsem tam ja, zena a deti a normalne to fungovalo, zarovka svitila presne podle pozadavku.

Jistě to skvěle funguje i v případě, že ty a manželka chcete mít rozsvíceno, ale děti chtějí mít zhasnuto. Ve chvíli, kdy je objektů Osoba víc, musíš zajistit (ne)svícení buď fackováním, tedy soutěží mezi objekty Osoba, anebo technicky, kdy k žárovce je přidán doplněk, který nedovolí změnu stavu častěji, než např. jednou za minutu.

OMG, pokud chci resit problem prioritizaci pristupu jednotlivych Osob k Zarovce, tak budu resit prioritizaci, s vlastni Zarovkou to nema nic spolecneho. To je tupe zarizeni, ktere sviti, kdyz do nej tece proud a nesviti, kdyz ne.
Alespon v mem svete to tak je.
Opravdu netusim, proc by proboha zarovka mela resit, jestli ji nekdo nezapina moc casto...

Pro reseni tohoto pozadavku zkratka pred zarovku predradim autorizacni ci jinou proxy, v pripade moji koupelny to budu ja, vystarano.

Pokud ti nestačí běžná žárovka, tak si zkus představit jinou, například v datovém projektoru. Také můžeš síťovým vypínačem ovládat své PC.

[kimec]

Mimochodem, když už jsme u té amatérské lingvistiky, tak ve filosofii se "objekt" odlišuje od "subjektu" právě tím, že je aktérem, původcem děje. A proto má i ta žárovka konat autonomně. Kdyby byla pasivní, nebyla by "objektem", ale "subjektem"

Asi ste chceli poukazat na tranzitivnost/netranzitivnost slovies ako nositelov vyznamu zmeny stavu u prijimatela... V prirodzenych jazykoch je nositel vyznamu prisudok, co je v drvivej vacsine sloveso (pre zjednodusenie).
Podla toho, ci je sloveso tranzitivne alebo nie je, sa "prijmatelom zmeny stavu" moze stat rovnako predmet (object) ako aj podmet (subject).

Problem s OOP je v tom, ze ludia nevedia kam so slovesami, ktore (paradoxne pre OOP dizajnerov) v prirodzenych jazykoch koduju podstatu vyznamu, ale v OOP jaksi nie su ustredna tema. Netranzitivne slovesa ludia este ako tak trafia ako virtualnu metodu na instancii, ktora meni jej stav. Ale co s tranzitivnymi slovesami? Kam ich dat? Staticke metody? No fuj.

To vsak nehovori nic o tom, ci ma ziarovka byt schopna konat autonomne.

[Standa Blábol]

na nějaké koncepty a SW inženýrství zvysoka šitujou a i tak píšou o řády lepší kód než někdo, kdo někde na VŠE “studoval koncepty”

Já tvrdím, že OOP koncepty lidem matou hlavy. Tahle tvoje historka je s tím tvrzením ortogonální

Ani ne. Jen tvrdím, že když má někdo PhD z astrofyziky, nějaký zcestný koncept ho nezmate, protože automaticky (podvědomě) ho bude ignorovat jako blbost. Ta laťka může být jinde, pro mnoho lidí je matoucím konceptem i for cyklus (bohužel i pro mnoho wannabe vývojářů). Když je někdo slabomyslný, mate mu hlavu OOP koncept stejně jako Okamura z SPD, dementní alkoholik na Hradě etc., to není vina OOP, ale onoho individua.

Amen.
A ja osobne nechapu, co je na OOP k nechapani.
Staci pouzivat selsky rozum pro dekompozici, napriklad, ze atribut User v session na webu neni modelem cloveka, ale ze je to model listku do pichacky daneho  cloveka na vratnici. Pak ho nenapadaj peachoviny jako User.zabookijSiObedVKantyne(), protoze kartotecni listky tohle obvykle nedelaji. A ze tam parti User.prichod(cas), user.odchod(cas) apod.
Nebo ze je logicke mit Lopata.naberUhli() a ne Uhli.naskakejNaLopatu().

Je zajimave, co jsou schopni lidi vymyslet za selmostroje a zakonity fail svedou na paradigma.

[Standa Blábol]

OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.
Zkousel jsem to dneska rano v koupelne, byl jsem tam ja, zena a deti a normalne to fungovalo, zarovka svitila presne podle pozadavku.

Jistě to skvěle funguje i v případě, že ty a manželka chcete mít rozsvíceno, ale děti chtějí mít zhasnuto. Ve chvíli, kdy je objektů Osoba víc, musíš zajistit (ne)svícení buď fackováním, tedy soutěží mezi objekty Osoba, anebo technicky, kdy k žárovce je přidán doplněk, který nedovolí změnu stavu častěji, než např. jednou za minutu.

OMG, pokud chci resit problem prioritizaci pristupu jednotlivych Osob k Zarovce, tak budu resit prioritizaci, s vlastni Zarovkou to nema nic spolecneho. To je tupe zarizeni, ktere sviti, kdyz do nej tece proud a nesviti, kdyz ne.
Alespon v mem svete to tak je.
Opravdu netusim, proc by proboha zarovka mela resit, jestli ji nekdo nezapina moc casto...

Pro reseni tohoto pozadavku zkratka pred zarovku predradim autorizacni ci jinou proxy, v pripade moji koupelny to budu ja, vystarano.

Pokud ti nestačí běžná žárovka, tak si zkus představit jinou, například v datovém projektoru. Také můžeš síťovým vypínačem ovládat své PC.

Tak jsem si to zkusil predstavit a vysledek je furt stejny.
Zarovka je furt tupa sklenena banka, ktera sviti, kdyz v tece proud.
A je uplne jedno jestli je spoustena vypinacem na stene, elektronikou projektoru.

Ano, sitovym vypinacem, muzu ovladat PC, klidne treba i vetrak, s faktem, co je to objekt Zarovka, to nema spojecneho lautr nic.

[Idris]

Mimochodem, když už jsme u té amatérské lingvistiky, tak ve filosofii se "objekt" odlišuje od "subjektu" právě tím, že je aktérem, původcem děje. A proto má i ta žárovka konat autonomně. Kdyby byla pasivní, nebyla by "objektem", ale "subjektem"

Asi ste chceli poukazat na tranzitivnost/netranzitivnost slovies ako nositelov vyznamu zmeny stavu u prijimatela... V prirodzenych jazykoch je nositel vyznamu prisudok, co je v drvivej vacsine sloveso (pre zjednodusenie).
Podla toho, ci je sloveso tranzitivne alebo nie je, sa "prijmatelom zmeny stavu" moze stat rovnako predmet (object) ako aj podmet (subject).

Problem s OOP je v tom, ze ludia nevedia kam so slovesami, ktore (paradoxne pre OOP dizajnerov) v prirodzenych jazykoch koduju podstatu vyznamu, ale v OOP jaksi nie su ustredna tema. Netranzitivne slovesa ludia este ako tak trafia ako virtualnu metodu na instancii, ktora meni jej stav. Ale co s tranzitivnymi slovesami? Kam ich dat? Staticke metody? No fuj.

To vsak nehovori nic o tom, ci ma ziarovka byt schopna konat autonomne.

Možná jsem příliš naivní, ale nestačilo by teda u přechodných sloves mít buď předmět nebo podmět jako vlastníka metody (this) a tu druhou gramatickou roli jako parametr? Teď tedy pomíjím rozdíl mezi gramatickou rolí a sémantickou funkcí, přechodnost (tranzitivita) je syntaktická záležitost, se sémantikou nijak nesouvisí, to jen, abychom se v tom neztratili, než se začneme věnovat pragmatice (aktuální členění větné, které má v programování také svou analogii).

[Kit]

... napriklad, ze atribut User v session na webu neni modelem cloveka, ale ze je to model listku do pichacky daneho  cloveka na vratnici. Pak ho nenapadaj peachoviny jako User.zabookijSiObedVKantyne(), protoze kartotecni listky tohle obvykle nedelaji. A ze tam parti User.prichod(cas), user.odchod(cas) apod.
Nebo ze je logicke mit Lopata.naberUhli() a ne Uhli.naskakejNaLopatu().

Je zajimave, co jsou schopni lidi vymyslet za selmostroje a zakonity fail svedou na paradigma.

Kdo má tedy kompetenci zabookování obědu v kantýně? User si vybere jídlo z Menu a pošle požadavek do Canteen.

Také bych raději použil User.add(new Prichod) a User.add(new Odchod). Případně Lopata.naber(new Uhli).