Omezená dědičnost (je něco lepšího než OOP?)

[BoneFlute]

Přesně! Tady  nejde o zatvrzelé odpůrce dědičnosti, ale o zatvrzelé zastánce dědičnosti pro nevhodná použití. Dědičnost na code reuse se používá proto, že máme blbý jazyky, který to lépe neuměj.

Je to přesně obráceně Dědičnost s virtuálními metodami je zobecnění postupu používaného na code reuse před OOP, dělalo se to tabulkou s pointery na specializované funkce, jakýsi předchůdce vtable.

Ano. A je to prostě zlo. Vzor template method je tomu korunou.

[Reklama]

[Mirek Prýmek]

Dědičnost "nějak" opravdu funguje, problém čtvercoobdélník je v Go snad ještě horší
http://play.golang.org/p/Xe9AyAx-Bh

To není dědičnost, ale skládání. To si bohužel taky dost lidí dneska plete...

Since we then defined Car as an anonymous field in Ferrari, the latter class automatically can call on all the visible behaviors/methods of the anonymous field type. So here, we have not subclassed a parent class, but composed it.

http://golangtutorials.blogspot.cz/2011/06/inheritance-and-subclassing-in-go-or.html

Jaký problém tam vidíš? Já žádný. Rozhodně ne takový, aby vedl k plamenným debatám o tom, jestli je čtverec obdélník...

[Mirek Prýmek]

Nemohou, protože čtverec není obdélník a kružnice není elipsa. Jsou to sourozenci mající společné rodiče.

Pokud tvrdíš, že nějaké entity "jsou sourozenci", tak implicitně používáš nějaké uspořádání. Jaké? Jsi si jistý, že ten, proti komu argumentuješ, nepracuje s nějakým jiným uspořádáním? Nemíjíte se právě proto?

Podle mě totiž v tomhle je doopravdy ten zakopaný pes: každá OOP učebnice pracuje s tím, že to uspořádání je to, co intuitivně můžeme nazvat "obecnost" (pojmu): Žárovka je Svítidlo, Pes je Savec atd. A všechny tyhle přiblblé debaty pramení z toho, že tohle uspořádání sice výborně funguje v teorii, na ideálních příkladech, ale v praxi máš jiná kritéria => jiné uspořádání => jinou hierarchii.

Nebo snad umíš precizně a jednoznačně nadefinovat jediné správné uspořádání objektů, které by vytvořilo tu jedinou správnou hierarchii dědičnosti?

[hawran diskuse]

To je dost nesmysl, bo code reuse.

Prakticky každá firma (co jsem viděl), která měla zoufale neudržitelný kód ho měla zoufalí proto, že dědily kůli code reuse. Takže za mě fakt ne!

To je lidma, ne děděním.

Takže když programátorům zakážeme používat dědění, tak bude problém vyřešen, ne?

Někteří diskutující by z obavy před porušením LSP nejraději tyhlety dědičnosti úplně zakázali a vyhodili z OOP.

Kůli LSP bych to nedělal, ale ano hlásím se k těm, které by dědění zakázali.

Tak. Developers by se neměli množit.

[Mirek Prýmek]

Tak. Developers by se neměli množit.

Množit se můžou, ale majetek by měli odkazovat charitě!

[Reklama]

[hawran diskuse]

Tak. Developers by se neměli množit.

Množit se můžou, ale majetek by měli odkazovat charitě!

Vole! 
(no offence!)

PS: samozřejmě, že charitě, kde jsem v nějaké "dozorčí" radě!

[hawran diskuse]

...
Nebo snad umíš precizně a jednoznačně nadefinovat jediné správné uspořádání objektů, které by vytvořilo tu jedinou správnou hierarchii dědičnosti?

To mi připomíná jednu úžasnou Sovákovu hlášku z "Kam čert nemůže" ... (něco jako až budu mít FAKT čas, tak se tomu budu opravdu věnovat)

[LSP]

Ano. A je to prostě zlo. Vzor template method je tomu korunou.

Proč zlo ? IMHO jinak než použitím pointerů na funkce/metody nelze code reuse realizovat. Nebo ano ?

Since we then defined Car as an anonymous field in Ferrari, the latter class automatically can call on all the visible behaviors/methods of the anonymous field type. So here, we have not subclassed a parent class, but composed it.

Možná tomu říkají skládání, výsledek z hlediska metod je stejný jako dědění nevirtuálních metod v OOP.
Proto nějaké problémy zůstávají, do čtverce vložíte obdélník a zkriplíte SetWidth SetHeight, úplně stejně jako v OOP.

[Logik]

Prymek:
"To není dědičnost, ale skládání"

Ano? Čím se to liší od dědičnosti v C++? Tam také když dědíš, tak vlastně do struktury přidáš data předka - a můžeš volat metody předka a když to dáš do metody, co očekává předka, tak to funguje..... Dědičnost ve většině jazyků prakticky funguje jako kompozice s nějakým syntatickým cukrem. To, co je v GO se chová jako dědičnost a tedy podle duck typing je dědičnost :-)

---

Jinak k debatě, jestli čtevere je nebo není obdélník - tak to samozřejmě závisí na definici obdélníku. Pokud ho definujeme jako:
1) "Čtyřuhelník, který má všechny úhly pravé", pak evidentně čtverec obdélník je.
Pokud ho ovšem definujeme jako:
2) "Čtyřuhelník, který má všechny úhly pravé a může si měnit šířku a výšku."
- Pak evidentně čtverec obdélník není.

Takže záleží, pro co píšeme program a jakou definici obdélníku používáme. Dokážu si představit i řešení, kdy mám obdélník dle definice 1) a z něj podědím jak čtverec, tak obdélník dle definice 2).

 

[Mirek Prýmek]

Možná tomu říkají skládání, výsledek z hlediska metod je stejný jako dědění nevirtuálních metod v OOP.
Proto nějaké problémy zůstávají, do čtverce vložíte obdélník a zkriplíte SetWidth SetHeight, úplně stejně jako v OOP.

Nejde o to, kdo čemu jak říká, ale o to, že dědění a skládání je jiný koncept. Rozdíl zhruba odpovídá tomu "mít" a "být", co tady zaznělo. A důsledek je mj. větší volnost: nikdo se nebude do krve hádat, jestli struktura může mít nějakou položku, tam je snad každýmu jasný, že to je buřt. To je jeden z příjemných čistě praktických důsledků. Jiné důsledky jsou třeba, že tu vnitřní položku můžu snadno vracet, vyměnit, nahradit úplně jinou strukturou atd. atd. Co přesně z toho platí pro Go, nevím, o tom se nechci hádat, znám ho jenom z rychlíku.

[JSH]

Proč zlo ? IMHO jinak než použitím pointerů na funkce/metody nelze code reuse realizovat. Nebo ano ?

Generika? C++ šablony? Makra? Code reuse se přece nemusí omezovat na spustitelný kód. Stačí když potřebné úpravy zvládne překladač sám.
[/quote]

[Mirek Prýmek]

Ano? Čím se to liší od dědičnosti v C++?

Třeba tím, že můžeš dělat "inferenci" (nevím, jaký je v tomhle kontextu správný termín) - pokud existují dané metody, pak je splněn daný protokol. Klidně i v případě, že jsi ty metody napsal deset let před tím a protokol definuješ až teď. (Nejsem si jistý, jestli tohle pro Go platí, jde mi o princip, ne o konkrétní jazyk)


Víc než s deděním bych to srovnával se starým dobrým mixinem.

[Mirek Prýmek]

Generika? C++ šablony? Makra? Code reuse se přece nemusí omezovat na spustitelný kód. Stačí když potřebné úpravy zvládne překladač sám.

...anebo právě ty protokoly. Chci generický bubblesort? Stačí mi, že pro strukturu existují funce compare a swap. Jak si je překladač najde, kam je uloží, kde je vezme, jak je spáruje s datovou strukturou, mi může být úplně buřt, já mám v kódu prostě

Kód: [Vybrat]

compare(jakakoliv_struktura,idx1,idx2)
a basta. O tom přece code reuse je - dělat věci genericky, za použití nějakého API. Callbacky jsou jenom jedna z možností implementace. Bohužel, když má někdo mozek nastavený na C, nebo nic jiného nepotkal, tak si to ani nedokáže představit...

[zboj]

Projed si historii diskuse. Problem nastane, kdyz mas mutable objekty.

To je vše o tom, že si někdo myslí, že čtverec je obdélník. Když pak zjistí, že některé vlastnosti na to nepasují, zavrhne dědění jako celek - s vaničkou vyleje i dítě. Přitom kdyby neudělal chybu v počátečním předpokladu, že čtverec == obdélník, tak by věděl, že tyto dvě třídy od sebe dědit nemohou.

Nebo dědit mohou, ale musí být na to objektový systém připraven, příkladem být může CLOS.

Nemohou, protože čtverec není obdélník a kružnice není elipsa. Jsou to sourozenci mající společné rodiče.

Proč tady musí být zatvrzelí odpůrci versus zatvrzelí zastánci dědičnosti? Je tak těžké pochopit, že někdy se dědičnost hodí a jindy ne? Že by sourozenecké třídy neměly mezi sebou dědit?

To je megahovadina, čtverec je z definice obdélník.

[Mirek Prýmek]

Ještě jedna poznámka a už končím

OOP může úplně s klidem vést i k tomu, že právě code reuse není možný - právě kvůli té myšlence spojení dat a metod. Když mám entitu reprezentovanou jenom daty - a navíc ještě pokud možno jednoduchými strukturami (FP přístup), tak třeba kde co můžu mít reprezentované dvojicí. A můžu mít jenom jednu funkci swap, která prvky dvojice prohodí. Pak mi stačí už jenom třeba makrem říct, že pro obdélník je otočení, zatímco pro jméno je to převod z Češtiny do Maďarštiny

Zkuste si tohle rozchodit v OOP - ideálně pomocí interface ISwappable, factory MakeSwappable, databáze mapující operaci swap na jeho význam pro různé objekty (samozřejmě hodnotou je pak konstanta z public final class SwappableSematics). A pak můžeme rozjet flame na téma, jestli je CzechToHungaryConvertor předek nebo dědic Generic2DObjectRotatorImmutable