Dědičnost dnes

anonym

Re:Dědičnost dnes
« Odpověď #75 kdy: 16. 01. 2017, 23:36:04 »
A proto: neplatí žádný vztah, že Syn dědí Fotra, ani že Kolo dědí Auto, ani že Škodovka dědí Auto, ani že Škodovka dědí ČeskouPostkomunistickouIndustrializaci, ani další kraviny. Jsou prostě jen objekty, Syn, Fotr, Kolo, Auto. Jaká je mezi nima skutečna dědičnost nebo agregace není nikomu známo. Existuje jen ta, kterou budeme používat, jen účel. Podstatou dědičnosti není nějaký reálný stav, podstatou dědičnosti je ÚČEL.

Např. ve Spring frameworku se reálně žádná dědičnost nepoužívá, všechno je tam "flat". A není vůbec od věci, použít dědičnost rovněž pro vynutí se duplicitnímu kódu v aplikaci, kterou prasilo několik týmů a jsou tam jistá její specifika.


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Dědičnost dnes
« Odpověď #76 kdy: 17. 01. 2017, 00:19:16 »
A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.) A taky si všímám, že spousta kódu, se kterým přijdu do styku se u dědičnosti tímto pravidlem neřídí. Možná je to proto, že ta dědičnost je těžká, a vývojáři ji neumí používat, ale pak je to tedy koncept na prd, a neměl by se používat vůbec.

Možná se tím neřídí proto, že se tím řídit nedá, protože to samotné pravidlo je blbost.

Příklad, ...

Můj názor.

OK. Ale obávám se, že jsem tvou argumentaci nepochopil.

AccountRow dědí Row - je ok
Voda dědí Náplň - je také ok.

Zda to má nějaké rozumné použití je věc jiná.
Row i Náplň je interface, protože Voda i Hrách mají specifické chování a společné pro ně je jen to, že jej lze někam naplnit.

Nevidím problém.

n

Re:Dědičnost dnes
« Odpověď #77 kdy: 17. 01. 2017, 07:39:54 »
A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.)

Ve spouste veci souhlasim, ci mam ze mam jiny nazor je nepodstatne, ale k vyse citovane vete:
S timhle je problem, napriklad znamy problem: ctverec vs obdelnik
Ctverec je specialni pripad obdelniku, ale opravdu od sebe nemohou dedit.

n

Re:Dědičnost dnes
« Odpověď #78 kdy: 17. 01. 2017, 07:49:17 »
A proto: neplatí žádný vztah, že Syn dědí Fotra, ani že Kolo dědí Auto, ani že Škodovka dědí Auto, ani že Škodovka dědí ČeskouPostkomunistickouIndustrializaci, ani další kraviny. Jsou prostě jen objekty, Syn, Fotr, Kolo, Auto. Jaká je mezi nima skutečna dědičnost nebo agregace není nikomu známo. Existuje jen ta, kterou budeme používat, jen účel. Podstatou dědičnosti není nějaký reálný stav, podstatou dědičnosti je ÚČEL.

Tak trochu, obecne mate samozrejme pravdu, ale: Kdyz se budete divat jen na aktualni UCEL, tak to dopadne spatne, protoze prijde zakaznik a bude po vas chtit pridat funkcionalitu, a pokud budete hledet pri modelovani jen na aktualni UCEL, tak to nejspis budete cele prepisovat. Oplati se zamyslet uz pri navrhu nad tim, co ten objekt predstavuje a jake jsou jeho vazby na okoli.
Jinak OOP pouzivam casto, ale vsespasne neni. Bohuzel nektere jazyky (jako napr Java) vas nuti to pouzivat ke vsemu, i kdyz jsou veci, ke kterym se opravdu nehodi, protoze spoustu casu travite usilim navrhnout smysluplnou hierarchii, i kdyz to nema smysl.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #79 kdy: 17. 01. 2017, 09:24:43 »
A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.)

Ve spouste veci souhlasim, ci mam ze mam jiny nazor je nepodstatne, ale k vyse citovane vete:
S timhle je problem, napriklad znamy problem: ctverec vs obdelnik
Ctverec je specialni pripad obdelniku, ale opravdu od sebe nemohou dedit.
Tohle se (nejen) tady řešilo už milionkrát a závěr vždy je, že mezi nimi dědičnost je. Jen na rootu se vždy najdou lidi, co o tom zas budou psát kraviny...  >:(


karel

Re:Dědičnost dnes
« Odpověď #80 kdy: 17. 01. 2017, 09:30:41 »
Např. návrhový vzor Role https://en.wikipedia.org/wiki/Role_Class_Model Můžeš třeba definovat školní systém tak, že Je třída Osoba, z ní dědí Učitel a Student. Ze Studenta dědí BakalářskýStudent a MagisterskýStudent. Celý systém je podle pravidla "is a" správně. Jenom neumožňuje přechod z bakaláře na magistra nebo ze studenta na učitele. "is a" je podmínka nutná, ale ne dostačující.

Jsi to spatne pochopil, na tom obrazku dole na te vazbe, je napsano "is a", ale neznamena to dedicnost, protoze ta se znaci v tom diagramu prazdnym trojuhelnickem. Praveze ta skola je modelovy priklad toho, ze se ma pouzit vazba "has a" a ne dedicnost.

Student nededi od cloveka. Cozpak je student vic clovekem nez delnik? Student ma smysl jen ve vztahu ke skole a ten vztah si nekdo vymyslel, je to pravni termin. Ty MAS VZTAH ("has a") vuci skole a tim je "student", "ucitel" atd... A muzes mit vic roli. Prave znamnka toho, ze by jsi potreboval roli zmenit nebo muzes mit vic roli (muzes byt ucitel i student i skolink zarovne? Muzes proc by ne.) je dalsi dobre voditko, proc to neni dedicnost.

Obecne plati, ze by jsi mel vzdycky delat co nejmene zavislosti. Literatura tomu rika loosely coupling, nicmene malokdo chape co tenhle buzz word znamena. Vazba "is a" je to nejsilnejsi co muze byt, kdyz  necim jsi, tak uz nemuzes byt  nicim jinym (ve svete trid). "has a",  casto implementovana jako promenna ve tride je mnohem volnejsi a kdekoliv si tak muzes rict, ze trida neco vlastni, tak je vzdy lepsi ji pouzit a kdyz si nejsem jistej, tak davam "has a".
Mě přijde že spíš je chyba na tvém přijímači. Student je člověk a ne že student má člověka (a druhý model by byl člověk má roli student). A ten vzor je o tom, že můžeš vytvořit 2 modely bezchybné podle pravidel dědičnosti, ale to co je podstatné, že si musíš vybrat ten, který dává smysl pro tvůj problém.

bob

Re:Dědičnost dnes
« Odpověď #81 kdy: 17. 01. 2017, 09:50:08 »
Mě přijde že spíš je chyba na tvém přijímači. Student je člověk a ne že student má člověka (a druhý model by byl člověk má roli student). A ten vzor je o tom, že můžeš vytvořit 2 modely bezchybné podle pravidel dědičnosti, ale to co je podstatné, že si musíš vybrat ten, který dává smysl pro tvůj problém.

Student neni clovek, student je role.
Druhy model, clovek ma roli studenta je spravne. A je to jidiny spravny model.

Nemuzes to dedit, protoze tam zadna dedicnost neni. Vybrat si muzes vzdycky, nekdy ale spatne.

Re:Dědičnost dnes
« Odpověď #82 kdy: 17. 01. 2017, 09:56:04 »
Mě přijde že spíš je chyba na tvém přijímači. Student je člověk a ne že student má člověka (a druhý model by byl člověk má roli student). A ten vzor je o tom, že můžeš vytvořit 2 modely bezchybné podle pravidel dědičnosti, ale to co je podstatné, že si musíš vybrat ten, který dává smysl pro tvůj problém.

Student neni clovek, student je role.
Druhy model, clovek ma roli studenta je spravne. A je to jidiny spravny model.

Nemuzes to dedit, protoze tam zadna dedicnost neni. Vybrat si muzes vzdycky, nekdy ale spatne.

Koukam, ze OOP sice deformuje mysleni, ale relacni pohled na vec ho dava do mixeru.

perceptron

Re:Dědičnost dnes
« Odpověď #83 kdy: 17. 01. 2017, 10:29:48 »
Citace
Tohle se (nejen) tady řešilo už milionkrát a závěr vždy je, že mezi nimi dědičnost je. Jen na rootu se vždy najdou lidi, co o tom zas budou psát kraviny.
zaver je ten ze vy si myslite ze dedicnost je a ostatni su blazni (milionkrat)


SB

Re:Dědičnost dnes
« Odpověď #84 kdy: 17. 01. 2017, 12:37:33 »
No právě, pokud neslouží na definici rozhraní a nemá protected metody nebo proměnné, nemá cenu z ní dědit, můžu k ní přistupovat z venku. Pokud má protected metody nebo proměnné, můžu z potomka ovlivnit její chování, takže jsem rozbil zapouzdření předka.

Tu první větu nechápu - dědění slouží k odvozování tříd.
Jestli vytvoříte novou podtřídu doplněnou o metody zpřístupňující některé vlastnosti, nadtřídy se to netýká a na zapouzdření jejích instancí to nemá (pochopitelně) vliv. S instancemi podtřídy si dělejte co chcete, jestli vytvoříte novou třídu děděním, nebo jejím celkovým přepisem (kde není žádný vztah k původní třídě), je buřt.

Např. návrhový vzor Role https://en.wikipedia.org/wiki/Role_Class_Model Můžeš třeba definovat školní systém tak, že Je třída Osoba, z ní dědí Učitel a Student. Ze Studenta dědí BakalářskýStudent a MagisterskýStudent. Celý systém je podle pravidla "is a" správně. Jenom neumožňuje přechod z bakaláře na magistra nebo ze studenta na učitele. "is a" je podmínka nutná, ale ne dostačující.

To je chybně namodelovaná situace. Učitel není Osobou, is-a neplatí. Použijte vzor Stav, Strategie, Role nebo něco podobného.

SB

Re:Dědičnost dnes
« Odpověď #85 kdy: 17. 01. 2017, 12:53:46 »
Trochu jsem to prehnal se silou vyjadreni, ale: tim ze date neco protected, se zavazujete k udrzovani rozhrani stejne jako kdyby to byla public, pokud je dana trida deditelna. Pouze k temto metodam nema pristup primy klient tridy, ale ten ktery ji dedi. Nemuzete odstranovat protected metody ani menit jejich funkci(respektive muzete, ale rovna se to zmene rozhrani, pokud neni zabraneni dedeni.)

Prosímvás, public sem teď nemíchejte, public určuje práci s instancí, ne uvnitř instance. Bavíme se o protected x private.
Samozřejmě, že protected znamená vazbu mezi třídou a podtřídou, ale to je přece podstata dědění. Když uděláte všechno private, jak bude podtřída využívat nadtřídu??? Chcete-li se vyhnout riziku změny v (třeba cizí) nadtřídě, udělejte si svoji samostatnou třídu. Tím ale přicházíte o výhodu dědění znovupoužitelnosti kódu, takže nejenže vám podtřídu nikdo nezkurví, ale ani se do ní nedostane požadovaná změna chování, opravy či rozšíření funkcionality. Prostě nedědíte. Jednoduché.

SB

Re:Dědičnost dnes
« Odpověď #86 kdy: 17. 01. 2017, 13:10:28 »
Tam, kde ste to vytrhli, som pisal o zneuzivani dedicnosti ako nastroja na odstranenie opakovania kodu.  Nepisal som nic o dedicnosti. Casting je v OOP jedna z moznosti vyuzitia polymorfizmu. Ako odkaz odporucam http://www.lmgtfy.com/?q=oop+casting

Vy jste zmatkař. Přepokládám, že jste chtěl napsat, že dědičnost se používá pro realizaci podtypového polymorfismu u jazyků s časnou vazbou, kde přetypování je způsobem sdělení překladači očekávané třídy instance, aby to vůbec mohl zavolat, protože se nepoužívá zasílání zpráv, ale přímé volání. Je to tak?

SB

Re:Dědičnost dnes
« Odpověď #87 kdy: 17. 01. 2017, 13:16:04 »
A jak teda obecně řešit problém, kdy mám třeba 5 různých typů dat, které trochu spolu souvisí, ale dědičnost tam nejde použít přesně proto, co jsi napsal. 5 různých tříd nesdílejích nic? 5 různých služeb pracující s nimi? Nebo použít pro služby generickou službu? A co ukládání? Je to obecně složité téma, ale jen tak jestli máš nějaké tipy k tomu. Málo dat a hodně logiky je jednodušší, ale když jsou data, která je potřeba mít, tak se to komplikuje.

Co je to "trochu souvisejí"?
Jestli ty entity nemají spolu (skoro) nic společného, tak je přece nebudu modelovat dohromady, protože nemají co sdílet, pak budou extra, jejich zpracování jinde bude extra a i způsob ukládání bude extra. I entity, které mají hodně společného, je možno klidně modelovat extra, ale přiděláte si tím práci.

SB

Re:Dědičnost dnes
« Odpověď #88 kdy: 17. 01. 2017, 13:19:25 »
Jeden ze základních problémů používání OOP je snaha pomocí dědičnosti (class hierarchy) modelovat realitu (nebo obecně doménu).

Ano, byla to jedna ze základních tezí vedoucí k propagaci a rozšíření OOP. Ale po třiceti (čtyřiceti?) letech si můžeme přiznat, že tohle naprosto selhalo.

Nebo někteří selhali? Vždyť i zde v diskusi někteří nedovedou rozpoznat generalizaci a specializaci.

SB

Re:Dědičnost dnes
« Odpověď #89 kdy: 17. 01. 2017, 13:23:57 »
False.
OOP je o komunikačním grafu agentů.
Dědičnost je víceméně z nouze ctnost.
OOP prostě nejde ke statickému typování.

Agenty jako (chytré) instance nesouvisejí s konstrukcí tříd pro výrobu (hloupých) instancí.
Dědičnost je mechanismus pro odvozování podobných tříd.
Původní OOP nikdy statické nebylo, to vzniklo až jako hybridní, původně imperativní jazyky. Z toho jsou pak mylně odvozovány obecné vlastnosti OOP.