Dědičnost dnes

[BoneFlute]

Obávám se, že toto je jeden z dalších příspěvků ukazujících nepochopení OOP - data z objektu nejde nijak vybalit, protože když je vybalíte, buďto získáte anemický model, nebo to není objekt (primitivní typy), takže to není OOP. Představa, že by delegace bylo nějaké "vybalování", je úplně nesmyslná.

Anemický model/objekt je taky objekt. Chyba programátora, že definuje debilní chování. Ale s OOP to nesouvisí ani ho neporušuje.

Primitivní typy v OOP neexistují. To je optimalizace Javy a spol. V OOP nemůžeš z objektu vybalit nějakou hodnotu primitivního typu. Můžeš jen objektu poslat zprávu a ona ti vrátí opět nějakou instanci nějakého objektu.

Podle mne není to vybalení nějaký problém. Prostě mám objekt, ten má stav, a ten stav si můžu vyserializovat - tedy to jsem si pojmenoval po svém to vybalení. No, a ten stav je samozřejmě taky složen z objektů (alespoň teoreticky).

Mě ta definice od JS přišla celkem trefná.

[Reklama]

[lopata]

Toto je ukazkovy priklad nespravneho pouzitia reflexie v Jave.  Public fieldy a metody su preto public, lebo su sucastou garantovaneho rozhrania, ktore sa v buducnosti bude menit len minimalne. Kdezto private metody, tie sa neodporuca takto hackovat, lebo je velmi pravdepodobne, ze v triede v buducnosti nebudu.  Javova reflexia je velmi nepohodlna a ani sa moc nepouziva, rychlo by vas to prznenie kodu preslo. Ked chcete pouzivat taketo dirty hacky, odporucam uz radsej AspectJ. Naviac pouzivate C-ckove formatovanie na java kod, kazi mi to oci.

To nevadí, že jsi to nepochopil, zkus to znovu a lépe. Nápověda: private v javě NIC NEGARANTUJE, protože k tomu jde různými způsoby přistupovat jako k public. Je jedno, jestli reflexi říkáš hack nebo co si o ní myslíš, protože nemůžeš nijak rozumně zabránit, aby ji kdokoliv použil měnil tvoje private fieldy.

P.S.
Kód si můžu formátovat jak chci, mně třeba kazí oči Java kód 

[JS]

Mě ta definice od JS přišla celkem trefná.

Nevim, jestli jsme si rozumeli, asi ano, slo mi predevsim o to, ze v OOP se predavaji data skryta v objektech (nelze k nim primo pristoupit), kdezto v FP se predavaji "naha" v tom smyslu, ze maji pomerne jasnou typovou definici. A to prirozene vede k tomu, ze se programy abstrahuji obracene - v FP se misto dat predavaji funkce, jejichz vnitrky (casti z kterych byly slozeny) jsou skryte.

V FP tak existuje flexibilita nalozit s temi daty jinak, nez by byly predurceny svymi metodami, a to je pravdepodobne to misto, kde jde o flexibilnejsi pristup.

A navic treba v Haskellu lze OOP realizovat pres typove tridy.

[BoneFlute]

ze maji pomerne jasnou typovou definici.

A navic treba v Haskellu lze OOP realizovat pres typove tridy.

Proto třeba osobně rozlišuju OOP/FP versus Typování jako dva různé koncepty.

[noef]

Mozna blba otazka, ale ja jsem myslel, ze kdyz knihovna v Haskellu nevyexportuje konstruktor, tak se k tomu nikdo krome knihovny nedostane. To neni zapouzdreni?

[Reklama]

[balki]

Toto je ukazkovy priklad nespravneho pouzitia reflexie v Jave.  Public fieldy a metody su preto public, lebo su sucastou garantovaneho rozhrania, ktore sa v buducnosti bude menit len minimalne. Kdezto private metody, tie sa neodporuca takto hackovat, lebo je velmi pravdepodobne, ze v triede v buducnosti nebudu.  Javova reflexia je velmi nepohodlna a ani sa moc nepouziva, rychlo by vas to prznenie kodu preslo. Ked chcete pouzivat taketo dirty hacky, odporucam uz radsej AspectJ. Naviac pouzivate C-ckove formatovanie na java kod, kazi mi to oci.

To nevadí, že jsi to nepochopil, zkus to znovu a lépe. Nápověda: private v javě NIC NEGARANTUJE, protože k tomu jde různými způsoby přistupovat jako k public. Je jedno, jestli reflexi říkáš hack nebo co si o ní myslíš, protože nemůžeš nijak rozumně zabránit, aby ji kdokoliv použil měnil tvoje private fieldy.

P.S.
Kód si můžu formátovat jak chci, mně třeba kazí oči Java kód 

Ten vas priklad je strasne pritiahnuty za vlasy, ano ide nieco, take, ked si date nohu za hlavu a trikrat sa otocite ale python skutocne nema viditelnost metod. Podtrzitkova konvencia sa velmi lahko porusuje a zvadza to k jej zneuzivaniu.

Kto programuje v jave drzi sa istych konvencii http://www.oracle.com/technetwork/java/codeconvtoc-136057.html. Dokument je neudrziavany, ale este stale platny a riadi sa nim napriklad formatter v netbeans.

[lopata]

Ten vas priklad je strasne pritiahnuty za vlasy, ano ide nieco, take, ked si date nohu za hlavu a trikrat sa otocite ale python skutocne nema viditelnost metod. Podtrzitkova konvencia sa velmi lahko porusuje a zvadza to k jej zneuzivaniu.

Kto programuje v jave drzi sa istych konvencii http://www.oracle.com/technetwork/java/codeconvtoc-136057.html. Dokument je neudrziavany, ale este stale platny a riadi sa nim napriklad formatter v netbeans.

Takže v Javě jde private porušit, ale nevadí to, protože kdo by to chtěl dělat, že. V Pythonu jde private porušit a je to hrozný problém, tím to ten jazyk naprosto diskvalifikuje... Typická Java logika Java zaslepence.

Ještě jednou, private v Javě i podtržitko v Pythonu mají úplně stejný význam, který říká:

"Tento field by se neměl měnit zvenku, není na to určený. Vím, že jde zvenku změnit, ale prosím nedělejte to. Něco by to mohlo ošklivě rozbít. Jestli ho opravdu budete měnit, dobře si to předtím rozmyslete, nenesu žádnou odpovědnost za nic. Děkuji za pochopení. S úctou Váš vývojář."

Uznávám, že napsat private je kratší. __ v pythonu je ještě kratší .

[gll]

Ten vas priklad je strasne pritiahnuty za vlasy, ano ide nieco, take, ked si date nohu za hlavu a trikrat sa otocite ale python skutocne nema viditelnost metod. Podtrzitkova konvencia sa velmi lahko porusuje a zvadza to k jej zneuzivaniu.

Platí to stejné, co jsem psal o metaclassách. Stačí porušování podtržítkové konvence v projektu zakázat. Znovu se zeptám na kontrétní zkušenost. Kdy vám porušení podtržítkové konvence zkomplikovalo práci? Já vím, že nikdy, protože jste v pythonu nikdy neprogramoval.

[ferren]

zbezne jsem preletel zacatek a konec tohoto fora a prijde mi ze jsem z jine planety....

dedicnost urcite neni ani mrtva, ani nemoderni, samozrejme neni ani nezbytna....da se taky samozrejme nahradit spousta jinymi pristupy, vse je to ale jen uplne stejnej syntaktickej cukr, podstatna cast je uplne identicka a to je HIERARCHIE ZASTUPITELNOSTI.

kdyz je tato hierachie spravna, dedicnost je velice pohodlna a ucinna...a naopak. to plati ale pro vsechny systemy, co maji ambici se pokouset ji nahradit.

takze se vse jen redukuje na schopnost vytvareni spravnych hierarchii pro KONKRETNI aplikaci. viz uz probranej virtualni problem ctverec vs obdelnik, kde me nenapada moc aplikaci (kreslicich, sumulacnich, numerickych) kde by vubec mel objekt ctverec rozumny duvod sve existence.
 teprv v aplikacich ktere objekt ctverec z nejakeho duvodu fakt potrebuji je jeho vztah k obdelniku zcela evidentne jednoznacny a vyplyva z duvodu jeho potreby existence...

[zboj]

zbezne jsem preletel zacatek a konec tohoto fora a prijde mi ze jsem z jine planety....

dedicnost urcite neni ani mrtva, ani nemoderni, samozrejme neni ani nezbytna....da se taky samozrejme nahradit spousta jinymi pristupy, vse je to ale jen uplne stejnej syntaktickej cukr, podstatna cast je uplne identicka a to je HIERARCHIE ZASTUPITELNOSTI.

kdyz je tato hierachie spravna, dedicnost je velice pohodlna a ucinna...a naopak. to plati ale pro vsechny systemy, co maji ambici se pokouset ji nahradit.

takze se vse jen redukuje na schopnost vytvareni spravnych hierarchii pro KONKRETNI aplikaci. viz uz probranej virtualni problem ctverec vs obdelnik, kde me nenapada moc aplikaci (kreslicich, sumulacnich, numerickych) kde by vubec mel objekt ctverec rozumny duvod sve existence.
 teprv v aplikacich ktere objekt ctverec z nejakeho duvodu fakt potrebuji je jeho vztah k obdelniku zcela evidentne jednoznacny a vyplyva z duvodu jeho potreby existence...

V raytracingu a obecně 3D grafice se geometrie používá, i 2D objekty. V diskusi šlo ale spíše o princip. Obecně jde v kódu především o polymorfismus, jehož lze dosáhnout dědičností jako jednou z metod. Co bylo kritizováno je zneužití dědičnosti k něčemu jinému.

[ferren]

zbezne jsem preletel zacatek a konec tohoto fora a prijde mi ze jsem z jine planety....

dedicnost urcite neni ani mrtva, ani nemoderni, samozrejme neni ani nezbytna....da se taky samozrejme nahradit spousta jinymi pristupy, vse je to ale jen uplne stejnej syntaktickej cukr, podstatna cast je uplne identicka a to je HIERARCHIE ZASTUPITELNOSTI.

kdyz je tato hierachie spravna, dedicnost je velice pohodlna a ucinna...a naopak. to plati ale pro vsechny systemy, co maji ambici se pokouset ji nahradit.

takze se vse jen redukuje na schopnost vytvareni spravnych hierarchii pro KONKRETNI aplikaci. viz uz probranej virtualni problem ctverec vs obdelnik, kde me nenapada moc aplikaci (kreslicich, sumulacnich, numerickych) kde by vubec mel objekt ctverec rozumny duvod sve existence.
 teprv v aplikacich ktere objekt ctverec z nejakeho duvodu fakt potrebuji je jeho vztah k obdelniku zcela evidentne jednoznacny a vyplyva z duvodu jeho potreby existence...

V raytracingu a obecně 3D grafice se geometrie používá, i 2D objekty. V diskusi šlo ale spíše o princip. Obecně jde v kódu především o polymorfismus, jehož lze dosáhnout dědičností jako jednou z metod. Co bylo kritizováno je zneužití dědičnosti k něčemu jinému.

vsak pisu, tam kde je treba, jsou zrejme zaroven i jeho vazby proc.....btw ja prave prochazim ze sveta 3d grafiky a v zadnym enginu, od vlastniho pres nekolik mainstreamovych komercnich ctverec nevidim, ale to je asi zas tradicne offtopic ;-)

[balki]

Ten vas priklad je strasne pritiahnuty za vlasy, ano ide nieco, take, ked si date nohu za hlavu a trikrat sa otocite ale python skutocne nema viditelnost metod. Podtrzitkova konvencia sa velmi lahko porusuje a zvadza to k jej zneuzivaniu.

Platí to stejné, co jsem psal o metaclassách. Stačí porušování podtržítkové konvence v projektu zakázat. Znovu se zeptám na kontrétní zkušenost. Kdy vám porušení podtržítkové konvence zkomplikovalo práci? Já vím, že nikdy, protože jste v pythonu nikdy neprogramoval.

Ale, programoval som v pythone nejake drobnosti do roboty. V praxi sa vacsinou pouziva na skriptovanie, na nic serioznejsie.  Plus som si skusal, ako sa v tom robi s opengl. Podtrzitkova konvencia sa mi zda prinajmensom nemudra. Je to nachylne k tomu, ze niekto si siahne tam, kam nema z lenivosti, alebo nevedomosti.

Z jasnovidectva ste asi nemali dobre znamky.

[Kiwi]

Podtrzitkova konvencia sa mi zda prinajmensom nemudra. Je to nachylne k tomu, ze niekto si siahne tam, kam nema z lenivosti, alebo nevedomosti.

Pane bože, ty to vidíš!

[SB]

On je mutable v ramci objektu, ktery je ale zvenci black box. Ono zapouzdreni neni, ze se vsechny promenne udelaji private a napisi k tomu gettery a settery. Zapouzdreni znamena, ze nevidis z venci, jak to uvnitr funguje a neleakuje ven implementace. Takze pokud to je vhodne tam klidne je public promenna a at si s tim kazdy dela co chce.

jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Navenek se mutable projevuje jako reference opacity, jak by řekli funkcionáři. Jsem tu jeden z posledních, komu má smysl vysvětlovat zapouzdření.
Observer je jen jedním ze způsobů komunikace mezi objekty/aktory, tvrzení, že se vzájemně neznají, je nesmysl, pak by to nemohlo fungovat. Máte v tom kapinku nejasno.

[SB]

Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.

Tahle odpověď mi připomíná kamaráda, když jsme hráli pingpong: "A kdo vyhraje?" "No přece ten, kdo bude mít nejvíc bodů."