Dědičnost dnes

[SB]

no, on je čtverec i speciálním případem pravidelného mnohoúhelníku (s n=4), což už je ale úplně jiný strom dědičnosti, ve kterém žádný jiný čtyřúhelník není

Správně. Ale to neznamená, že musím (třeba násobným) děděním postihnout tyto vlastnosti. Dědění slouží pro konstrukci funkční třídy, ne pro splnění všech těchto závislostí. Proto platí, že vytvořit čtverec lze několika způsoby včetně zcela nového zápisu. Vývojář musí vědět, co se mu vyplatí. A v nejhorším vždy platí, že to můžu vyrobit od základu. Užití dědění není povinné!

[Reklama]

[SB]

Myslim, ze tohle pro traity napr. ve Scale neplati. Trait si muze urcit do ceho bude namixovan (v podstate interface "this") a muze obsahovat jak stav, tak zpracovani. Casto tak rozdeluji velke tridy do nekolika traitu (a souboru) kvuli prehlednosti...

Pak se skládání traits podobá násobné dědičnosti. Já to slyšel a je jako mixins. Ale je to šumák, víme, o co jde.

[SB]

Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.

Doktorát z čeho? Historie "starých Slováků"? Podle toho, jak tu trolíš, nemáš ani základku a někde v Horních Uhrách se opíráš o lopatu a v jednom kuse nasáváš borovičku. Tak nás všechny ušetř těch kravin a dej si odchod.

Bez urážek!
Pan Balki si může veškeré uvedené termíny dohledat.

[karel]

Ale existuju best practices, prosim netykajte mi.

Best practices nejsou jen jedny. Každých pár let je za best practices považováno něco jiného. Kde vám tykám?

Prepacte, netykate mi, zle som pozeral. Ale Pouzitie dedenia miesto delegacie pri duplicite kodu nebola best practice snad nikdy. Da sa to tak robit, iba ak podobne dedenie dava zmysel. Tu je relevantna litertura https://www.google.sk/search?q=compsition+over+inheritance .  https://en.wikipedia.org/wiki/Delegation_pattern.   

Typicky z vlasy pritiahnuty priklad je, ked osoba ma Usta s metodou papaj().  Potom ale clovek poterebuje tiez jest a tak  moze nastat  Clovek extends Usta.  Podobne je to pritiahnute s vynimanim duplikovaneho kodu do parenta. Ano, da sa to, len to sposobuje problemy.

To je jeden příklad špatného použití, ale i správná použití dědičnosti slouží k odstranění duplicity.

https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Code_reuse

Je otázka, jak moc je ten váš příklad špatný. Uživatele té třídy by nemělo zajímat, jak k té metodě přišla. Dejme tomu, že je to v některých jazycích špatné použití, ale například v pythonu se dědičnost používá k implementaci mixinů podobným způsobem jako ve vašem příkladu.

Čet sis tu stránku na wikipedii (teď navíc nehodnotím jak je wikipedia autoritativní zdroj, zvlášť odstavec plný odkazů "citation needed")? Mixin je v zásadě trochu jiný princip než dědění i když se často pomocí dědění implementuje. Dálší je private dědičnost v C++, která je ale z principu rozbitá a rozhodně nedoporučuju to používat (přetypuješ na předka a můžeš volat privatní zděděné metody). A v celém tom odstavci popisujou antipattern fragile base class, ke kterému právě code reuse pomocí dědičnosti často vede. Zkus teda ukázat nějaký příklad použití, který je dobře. Celá tahle diskuze je o tom, že vždycky se řekne, to bylo špatně použité, ale ještě jsem neviděl příklad toho dobrého použití.

[SB]

...Na tomto problému je dobré jen to, že je vidět, že v různých situacích se hodí různá řešení a recept na to jediné správné prostě bez znalosti dalšího kontextu není.

Zde se hodí odkaz, kde to autor shrnul za nás: http://prog-story.technicalmuseum.cz/images/dokumenty/Programovani-TSW-1975-2014/2001/2001-15.pdf
Autor danou problematiku rozebírá a uvádí, že v různých fázích analýzy a implementace se může hierarchie tříd jevit jinak.

[Reklama]

[SB]

Co to je "původní OOP"? Něco ještě před Simulou? Protože pojetí tříd, objektů, dědičnosti a virtuálních funkcí v jazyce Simula 67 je blíž dnešním jazykům jako C++ nebo Java, než Smalltalku, který vznikl až po Simule.

Pro mě je nejohebnější koncept OOP ten od Kaye ze Smalltalku. Třeba je něco lepšího, ale nevím o tom.

[SB]

To, že se zavede nějaký pojem, ještě neznamená, že pod něj nelze zahrnout něco, co existovalo už předtím. Už proto, že Alan Kay nestavěl na zelené louce. Ano, můžeme OOP chápat omezeně tak, jak funguje ve Smalltalku. Alternativně můžeme pod OOP zahrnout i využití stejných nebo podobných principů v jiných jazycích trochu jiným způsobem. Myslím, že programování není o dogmatickém dodržování nějakých oblíbených naučených teoretických principů, ale o pragmatickém hledání fungujícího řešení (kde pod pojem "fungující" zahrnuji podle okolností i srozumitelnost, rozšiřitelnost, dodržení smysluplných konvencí, aj.).

Ano, Kay určitě vycházel ze Simuly. Slovo "omezeně" je myslím v souvislosti se Smalltalkem vyloženě nevhodné, kdy Smalltalk si např. nevyrobil omezení v podobě podtypového polymorfismu a silný zůstává v pozdní vazbě a metatřídní implementaci tříd. To má dnes jen pár(?) jazyků.

[karel]

Ještě teda z článku na wikipedii mě zaujala část: https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Issues_and_alternatives

Konrétně věta: "Reportedly, Java inventor James Gosling has spoken against implementation inheritance, stating that he would not include it if he were to redesign Java."

Takže evidentně si za děděním chování nestojí ani autoři jazyka, který je tímhle způsobem programování asi nejznámější.

[ava]

Někdo totiž může říct, že obdelník může být speciální případ cltverce...

Obdélník nesplňuje shodnou délku stran čtverce, proto nejde o specializaci. Při specializaci obdélník -> čtverec jsou všechna pravidla zachována a jedno přibývá. Co je na tom nejasného?

Jak psal Satai Nekola, ctverec dedici z obdelnika je v pohode pouze, pokud je immutable, jinak porusuje Liskov Substitution Principle, tedy instance podtypu ma stejne ocekavane vlastnosti jako instance nadtypu.

Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

b = obdelnik.obsah()/obdelnik.a()
obdelnik.setSideA(10)
obdelnik.obsah() == b * obdelnik.a()

coz muze prekvapit a potrapit.

No a kdyz z nej podedim ctverec, tam je zase ocekavana vlastnost, ze delka A == delka B.

A ted co se ma stat, kdyz zavolam setSideA na ctverci jakozto potomku obdelnika? At vymyslis jakekoliv reseni, vzdy to bude z nektere strany davat neocekavane chovani.

Pokud jsou obdelnik a ctverec immutable, timto neduhem netrpi (netvrdim nic o tom, co se ocekava, ze se stane, kdyz zavolam setSideA, protoze zadna takova mutator metoda neexistuje).

Tohle si myslim je dost zakladni princip, ktery by kazdy programator v jazycich s subtype polymorfismem mel znat.

[Kiwi]

Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

[Kiwi]

Jinak by treba neplatila posloupnost

b = obdelnik.obsah()/obdelnik.a()
obdelnik.setSideA(10)
obdelnik.obsah() == b * obdelnik.a()

coz muze prekvapit a potrapit.

Aj! Však je to taky ze své podstaty totálně špatně! "B", "A" i obsah jsou vlastnosti objektu, které máte získávat od něj. A ne si je počítat bokem vedle. Vždyť jste tu předvedl naprosto flagrantní porušení zapouzdření!

Nicméně zařazuji do své sbírky odstrašujících příkladů. 

[karel]

Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Já teda očekávám, že program dělá jen věci které jsou v něm jasně napsané a ne věci o kterých se nikde nezmiňuje. Tak jsem asi špatný programátor a dávám do svých programů málo matematických chytáků.

[Ondra Satai Nekola]

Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Ale no tak. Kód se píše pro lidi a pokud setA má neočekávané vedlejší efekty na b a odpálí navíc jaderné hlavice, je to očividně špatný návrh.

Že takové omezení neplyne z nějaké matematické představy, co máš, je jedno.

Naopak pokud se člověk chce matematikou inspirovat, tak se celé téhle opičárně raději vyhne úplně.

[Inkvizitor]

Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Prosil bych nejaky odkaz. Jestlize zmena strany u obdelnika *obecne* znamena, ze se druhy rozmer necha jak byl (a to je zcela rozumne ocekavani), proc by to u ctverce (ktery je take obdelnikem, kdyz jsme to takhle "chytre" nadefinovali) melo byt jinak.

[Ondra Satai Nekola]

Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Prosil bych nejaky odkaz. Jestlize zmena strany u obdelnika *obecne* znamena, ze se druhy rozmer necha jak byl (a to je zcela rozumne ocekavani), proc by to u ctverce (ktery je take obdelnikem, kdyz jsme to takhle "chytre" nadefinovali) melo byt jinak.

To neřeš. Tohle je očividně porušení kontraktu. Ať už někde popsaného ve specce, definovaného testy nebo očekávaného.