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

[JSH]

...a tomu se, milé děti, říká "znovupoužitelnost kódu v OOP"

To je ale překvápko. Z různých zadání vypadla různá řešení

Možná jsem naivní ale mám pocit, že ta bublina nekritického obdivu OOP začíná trochu splaskávat. Jsem zvědavý, co za stříbrnou kulku přijde teď.

[Reklama]

[Mirek Prýmek]

To je ale překvápko. Z různých zadání vypadla různá řešení

Přesněji řečeno vzájemně nekompatibilní, znovunepoužitelné implementace jedné a téže věci

[Mirek Prýmek]

Nicméně já bych se vrátil k původnímu dotazu a podpořil bych Kit-a: stude, koukni se na jazyky, kde se na dědičnost nehraje a místo toho se používají volně kombinovatelné protokoly. Největší šanci na mainstreamovost má asi Go.

Různé implementace podobného principu:

Go: https://tour.golang.org/methods/5
Elixir: http://elixir-lang.org/getting-started/protocols.html
Haskell: https://www.haskell.org/tutorial/classes.html
Rust: https://doc.rust-lang.org/book/traits.html

[LSP]

Možná jsem naivní ale mám pocit, že ta bublina nekritického obdivu OOP začíná trochu splaskávat. Jsem zvědavý, co za stříbrnou kulku přijde teď.

Splaskává pouze bublina vymyšlených nesplnitelných očekávání od OOP.

Nicméně já bych se vrátil k původnímu dotazu a podpořil bych Kit-a: stude, koukni se na jazyky, kde se na dědičnost nehraje a místo toho se používají volně kombinovatelné protokoly. Největší šanci na mainstreamovost má asi Go.

Zrovna Go to má takhle: "Dědí" se jenom interface, nejsou virtuální metody a předek tak nemůže zavolat metodu z potomka. Pomůže to k něčemu ?

[zboj]

Nicméně já bych se vrátil k původnímu dotazu a podpořil bych Kit-a: stude, koukni se na jazyky, kde se na dědičnost nehraje a místo toho se používají volně kombinovatelné protokoly. Největší šanci na mainstreamovost má asi Go.

Různé implementace podobného principu:

Go: https://tour.golang.org/methods/5
Elixir: http://elixir-lang.org/getting-started/protocols.html
Haskell: https://www.haskell.org/tutorial/classes.html
Rust: https://doc.rust-lang.org/book/traits.html

...a Swift

[Reklama]

[Mirek Prýmek]

Zrovna Go to má takhle: "Dědí" se jenom interface, nejsou virtuální metody a předek tak nemůže zavolat metodu z potomka. Pomůže to k něčemu ?

Nedědí se nic. Předek nemůže volat metodu potomka, protože žádný předek a potomek neexistuje. Pomůže to k tomu, že se nebudou vést nekonečné debaty, jestli je čtverec potomek obdélníka nebo obdélník předem čtverce.

[zboj]

Zrovna Go to má takhle: "Dědí" se jenom interface, nejsou virtuální metody a předek tak nemůže zavolat metodu z potomka. Pomůže to k něčemu ?

Nedědí se nic. Předek nemůže volat metodu potomka, protože žádný předek a potomek neexistuje. Pomůže to k tomu, že se nebudou vést nekonečné debaty, jestli je čtverec potomek obdélníka nebo obdélník předem čtverce.

Když se vezme čtverec, obdélník, kosočtverec a rovnoběžník, tak dědičnost vytvoří "diamant". Nicméně i tak se dá třeba výpočet plochy napsat jen jednou.

[LSP]

Nedědí se nic. Předek nemůže volat metodu potomka, protože žádný předek a potomek neexistuje. Pomůže to k tomu, že se nebudou vést nekonečné debaty, jestli je čtverec potomek obdélníka nebo obdélník předem čtverce.

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

[Goheeca]

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.

[Kit]

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?

[Goheeca]

Já jen poukazuji na to, že v některých systémech, to lze snadno provést a nejsme omezeni jako v jiných systémech. Na problém čteverec-obdélník lze pohlížet oběma způsoby, nejde říct, že to jsou vždy jen sourozenci nebo vždy jen rodič-dítě.

[LSP]

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?

Protože code reuse. Mít čtyři různé objekty je teoreticky správné, ale prakticky nežádoucí a kontraproduktivní. Stejně ty čtyři různé objekty budou jenom boiler plate pro volání funkcí společných pro všechny čtyři varianty.

[BoneFlute]

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.

[BoneFlute]

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?

Protože code reuse. Mít čtyři různé objekty je teoreticky správné, ale prakticky nežádoucí a kontraproduktivní. Stejně ty čtyři různé objekty budou jenom boiler plate pro volání funkcí společných pro všechny čtyři varianty.

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.

[LSP]

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.