Dědičnost dnes

n

Re:Dědičnost dnes
« Odpověď #45 kdy: 16. 01. 2017, 12:56:27 »

Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je presny priklad toho, proc jsou s tim problemy. Lidi s nastrojema neumi pracovat a pak si stezuji, ze jsou ty nastroje nanic. Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public. Navzdy se zavazujete k tomu rozhrani a uz to nikdy nesmite menit. Lidi si to ale neuvedomuji a pak svaluji vinu napriklad na dedicnost, ale ten problem je uplne nekde jinde.


SB

Re:Dědičnost dnes
« Odpověď #46 kdy: 16. 01. 2017, 13:00:58 »
...Použití dědičnosti zpravidla redukuje opakování kódu, i když to není primárním účelem.

A co je primárním účelem? Polymorfismus? Pouze u jazyků s  podtypovým polymorfismem je to nutností.

karel

Re:Dědičnost dnes
« Odpověď #47 kdy: 16. 01. 2017, 13:02:15 »

Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je presny priklad toho, proc jsou s tim problemy. Lidi s nastrojema neumi pracovat a pak si stezuji, ze jsou ty nastroje nanic. Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public. Navzdy se zavazujete k tomu rozhrani a uz to nikdy nesmite menit. Lidi si to ale neuvedomuji a pak svaluji vinu napriklad na dedicnost, ale ten problem je uplne nekde jinde.
Já jsem spíš chtěl říct, že většinou pokud se zbavíš protected proměnných, zbavíš se i důvodu pro použití dědičnosti a vrátíš se zase zpět k "posílání zpráv" mezi objekty. Dědičnost není celá špatně, ale historicky je hodně nadužívaná a svádí k tomu právě i způsob výuky OOP.

SB

Re:Dědičnost dnes
« Odpověď #48 kdy: 16. 01. 2017, 13:13:11 »
Podporuje to vznik roznych zkriplenych objektov, ktorych ucel nie je jasny, plus si tym programator zbytocne zahlcuje hierarchiu dedicnosti.

Ked sa pouzije casting potomka na rodica, mal by tento casting v ramci polymorfizmu fungovat. Pri DRY objektoch tomu tak nebyva.

Jak dědičnost kriplí instance podtříd? Jak dědičnost způsobuje bezúčelnost objektů? Jak specializace zahlcuje hierarchii? Co má společného přetypování s polymorfismem? Co je "DRY objekt"? O čem to vůbec mluvíte???

Re:Dědičnost dnes
« Odpověď #49 kdy: 16. 01. 2017, 13:17:00 »

Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je presny priklad toho, proc jsou s tim problemy. Lidi s nastrojema neumi pracovat a pak si stezuji, ze jsou ty nastroje nanic. Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public. Navzdy se zavazujete k tomu rozhrani a uz to nikdy nesmite menit. Lidi si to ale neuvedomuji a pak svaluji vinu napriklad na dedicnost, ale ten problem je uplne nekde jinde.
Já jsem spíš chtěl říct, že většinou pokud se zbavíš protected proměnných, zbavíš se i důvodu pro použití dědičnosti a vrátíš se zase zpět k "posílání zpráv" mezi objekty. Dědičnost není celá špatně, ale historicky je hodně nadužívaná a svádí k tomu právě i způsob výuky OOP.

Moje podezreni je, ze primarni duvod je, ze dedicnost je tezka. Takze se ji venuje hodne prostoru pri vyuce. A proto skoro vsichni hned do zacatku dostanou klapky pred oci. (A nasekaji spoustu problemu, protoze dedicnost je tezka. A protoze nasekali problemy, tak stoji za to dedicnost ucit co nejdusledneji ;) )


SB

Re:Dědičnost dnes
« Odpověď #50 kdy: 16. 01. 2017, 13:37:31 »
Většině diskutujících uniká je, že dědičnost v jazycích jako Java, C++ apod. representuje vlastně 3 koncepty. Je to dědění dat (většinou nechci, porušuje zapouzdření, lepší je použít skládání), dědění chování (většinou nechci, vede k fragile base class a porušuje zapouzdření), definice rozhraní(většinou chci, pomáhá k využití polymorfismu, pomáhá strukturovat kód - neprogramuju proti implementaci). Interface je dokonce často oddělen od dědičnosti - Java, C#.

3x chyba:
Jak porušuje dědění zapouzdření?!
Dědění chování potřebuju, abych jej nemusel vytvářet znovu.
Na definici rozhraní je rozhraní, k tomu třída neslouží!

Protože často ani "is a" neznamená, že je správné použít dědění ve smyslu dědění chování nebo dat a jde mi jen o interface.

??? Uveďte příklad.

balki

Re:Dědičnost dnes
« Odpověď #51 kdy: 16. 01. 2017, 14:19:18 »
Podporuje to vznik roznych zkriplenych objektov, ktorych ucel nie je jasny, plus si tym programator zbytocne zahlcuje hierarchiu dedicnosti.

Ked sa pouzije casting potomka na rodica, mal by tento casting v ramci polymorfizmu fungovat. Pri DRY objektoch tomu tak nebyva.

Jak dědičnost kriplí instance podtříd? Jak dědičnost způsobuje bezúčelnost objektů? Jak specializace zahlcuje hierarchii? Co má společného přetypování s polymorfismem? Co je "DRY objekt"? O čem to vůbec mluvíte???

Vytrhavate veci z kontextu a reagujete mimo misu. Najprv si precitajte, o com som pisal a potom reagujte. Zda sa ze si musite doplnit znalosti.

"DRY objekt", som pouzil ako pejorativum. Take neexistuje, ale z kontextu je jasne hadam na co myslim.

SB

Re:Dědičnost dnes
« Odpověď #52 kdy: 16. 01. 2017, 14:21:21 »
Někdo ještě používá protected atributy? Měly by být všechny privátní.

V okamžiku, kdy použijete vlastnosti a metody private, oddělíte od sebe prostory jednotlivých tříd v daném řetězu dědičnosti, protože se k těmto prvkům již nedostanete. To je zcela odlišný koncept od použití protected, kdy každá třída je souhrnem svých nadtříd. Jestliže dědím proto, abych mohl využívat již hotové a specializovat, je pro mě skytí vlastností v nadtřídách kontraproduktivní. Neboli všechny private určitě ne.

Kit

Re:Dědičnost dnes
« Odpověď #53 kdy: 16. 01. 2017, 14:33:57 »
Někdo ještě používá protected atributy? Měly by být všechny privátní.

V okamžiku, kdy použijete vlastnosti a metody private, oddělíte od sebe prostory jednotlivých tříd v daném řetězu dědičnosti, protože se k těmto prvkům již nedostanete. To je zcela odlišný koncept od použití protected, kdy každá třída je souhrnem svých nadtříd. Jestliže dědím proto, abych mohl využívat již hotové a specializovat, je pro mě skytí vlastností v nadtřídách kontraproduktivní. Neboli všechny private určitě ne.

Pokud mám ve třídě privátní atributy a veřejné metody, tak pro potomky budou přístupné pouze metody. Víc nepotřebuji. Potomek nemá důvod na atributy sahat, o to se starají metody nadtřídy.

spasitel

Re:Dědičnost dnes
« Odpověď #54 kdy: 16. 01. 2017, 14:37:35 »
ajajaaaj, dalsi diskuze jde do kytek. kazdej si tady honi svy ego, ma svuj nazor a ten je proste neprustrelnej. panove, jdete na leceni, protoze uroven vasich prispevku ma hodnotu kecu v hospode.

SB

Re:Dědičnost dnes
« Odpověď #55 kdy: 16. 01. 2017, 14:38:04 »
Souhlas a tady se nabízí otázka, když je ta třída správně zapouzdřená opravdu z ní potom chci dědit? IMHO nechci a je lepší použít skládání.

Specializace nemá se zapouzdřením co dělat, zapouzdření můžete porušit zpřístupněním metody či vlastnosti na public nebo metodou public, ne vytvořením podtřídy, která nadtřídu nijak neovlivňuje.
Skládáním nemůžete změnit vnitřní chování objektu, tím můžete pouze využít vnější funkcionalitu skládaného objektu, a to je dost podstatný rozdíl. Takže univerzální použití skládání padá.

SB

Re:Dědičnost dnes
« Odpověď #56 kdy: 16. 01. 2017, 14:45:28 »
Každý asi zažil šílené hierarchie dědění, kde pomalu každá metoda volá nejdřív implementaci předka nebo kvanta protected atributů, co se ve většině tříd nikdy nepoužijí nebo se přes ně předávají argumenty funkce, ale ani jedno nejde rychle opravit bez rozbití poloviny systému.

To je běžným důsledkem nejen chybného použití dědění a skládání, ale taky chybným rozdělením funkcionalit mezi třídy a v důsledku chybným zapouzdřením a polymorfismem. Na to přesný návod neexistuje, to se prostě musí umět. Každopádně OOP za to nemůže.

...Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public...

To je samozřejmě nesmysl, právě protected dovoluje díky dědičnosti znovuvyužití hotové funkcionality v rámci zřetězení tříd bez nutnosti složitého delegování či opakování, na zapouzdření instance to pochopitelně vliv nemá.

SB

Re:Dědičnost dnes
« Odpověď #57 kdy: 16. 01. 2017, 14:55:36 »
Moje podezreni je, ze primarni duvod je, ze dedicnost je tezka...

Dědičnost vůbec není těžká, je jen složitě vysvětlovaná, a to ještě na jazycích, co ji potřebují k polymorfismu, takže se tak mísí 2 koncepty a posluchač v tom má bordel.
Dědičnost si stačí představit jako tu původní, smalltalkovou (vše protected), kdy každá podtřída je to samé, jako bych opsal celou nadtřídu a nahradil/doplnil jen to, co je jiné. Neboli dědičnost lze nahradit právě takovýmto přepisováním celých tříd (s následným porušením DRY). Teprve potom lze přidat vysvětlení doprasených implementací z jiných jazyků.

SB

Re:Dědičnost dnes
« Odpověď #58 kdy: 16. 01. 2017, 15:00:04 »
Vytrhavate veci z kontextu a reagujete mimo misu. Najprv si precitajte, o com som pisal a potom reagujte. Zda sa ze si musite doplnit znalosti.

"DRY objekt", som pouzil ako pejorativum. Take neexistuje, ale z kontextu je jasne hadam na co myslim.

Četl jsem vše od začátku. Asi mluvíme každý o něčem jiném. Odkazy k doplnění znalostí by mohly nedorozumění vyjasnit.

SB

Re:Dědičnost dnes
« Odpověď #59 kdy: 16. 01. 2017, 15:12:43 »
Pokud mám ve třídě privátní atributy a veřejné metody, tak pro potomky budou přístupné pouze metody. Víc nepotřebuji. Potomek nemá důvod na atributy sahat, o to se starají metody nadtřídy.

Veřejné metody neslouží k přístupu uvnitř třídy (i když můžou), ale k přístupu z vně instance. V případě, že budou všechny public, tak jste nemusel používat dědění, ale skládání, protože část nadtřídy se v instanci chová jako složený, zapouzdřený, samostatný objekt. Otázkou je, zda je takový model v pořádku.

Opět: Vaše pojetí nadtřídy je pojetím izolované entity vložené do podtřídy. Přitom podstatou specializace je pravidlo "is-a", takže není důvod, aby podtřída nepracovala s entitami z nadtřídy, dokonce je to záhodno. Máte-li potřebu oddělovat mezi sebou části z řetězce hierarchie (přičemž pořád platí, že nadtřída je podtřídami nedotčena), snažíte se vyrábět něco jako skládání.