Dědičnost dnes

[n]

Dedicnost je dobra a nepouziva sa na redukciu opakovania kodu. (aj ked k redukcii opakovania kodu moze dojst, ak je to tak spravne)  Staci taketo vyjadrenie?

Ano, stačí.

Začátky chybného uvažování je již ve špatných učebnicích, ve kterých jsou nesmysly typu "B extends A" nebo "Bar extends Foo". Přitom ani v jednom případě to neplatí. Chudák čtenář si pak myslí, že se dědičnost používá na redukci opakování kódu a už se veze po špatné koleji.

Tojo, vizualne uz na prvni pohled to je blbe, ale doufam, ze snad ve vsech ucebnicich nekolikrat zdurazni tu zakladni, nutnout podminku cos psal vyse.

[Reklama]

[jpu]

dedicnost bezne pouzivam napr. (C#):

Kód [Vybrat] Rozbalit

public class ViewModelBase : INotifyPropertyChanged
{
    public void NotifyPropertyChanged ....

}

public class CustomerViewModel : ViewModelBase
{
}

inheritance hierarchy represents an "is-a" relationship and not a "has-a" relationship

[Kit]

Začátky chybného uvažování je již ve špatných učebnicích, ve kterých jsou nesmysly typu "B extends A" nebo "Bar extends Foo". Přitom ani v jednom případě to neplatí. Chudák čtenář si pak myslí, že se dědičnost používá na redukci opakování kódu a už se veze po špatné koleji.

Tojo, vizualne uz na prvni pohled to je blbe, ale doufam, ze snad ve vsech ucebnicich nekolikrat zdurazni tu zakladni, nutnout podminku cos psal vyse.

Je také nutné si uvědomit, jak se takové učebnice čtou. Čtenář se začte do zdrojového kódu, protože je hezky vyznačen, ale tu důležitou "omáčku kolem" si buď nepřečte, anebo přečte a nepochopí. V hlavě mu pak zbude jen ten nepovedený příklad s tím, že to snad pochopí později.

Ukázkovým příkladem chybného pochopení dědičnosti je pak třeba známý "Cyklista extends Žába", který nepopisuje cyklistu, který umí skákat, ale žábu, která umí jezdit na kole. A takových "žab" bývají bohužel plné zdrojáky.

[dustin]

Jo, na příklady Foo a Bar jsem také alergický (nejen v ukázkách dědičnosti), daleko užitečnější by bylo používat reálné příklady. Ale nemyslím si, že by rozumný vývojář nepochopil, že jde o "is a" a ne o "has a".

[karel]

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#.

Podle mě OOP jazyk vůbec nemusí umožňovat dědit data a chování a přesto se v tom bude dobře programovat bez duplikování kódu. 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. 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.

IMHO podle mě pro objektové programování je nejdůležitější programovat proti rozhraní, dodržovat zapouzdření a každá třída musí mít jenom jednu roli (signle responsibility). Pokud tohle dodržuju, dědičnost (nepočítám implementaci interface) mi z programu z velké části zmizí a spíš slouží k modelování dat než k deduplikaci kódu.

[Reklama]

[SB]

Používáte dnes v OOP často dědičnost? Není ta doba už pryč?

Dědičnost nemá co dělat s dobou či módou, je to technologická záležitost! Podle módy programují lempli.

Stále narážím na lidi, kteří milují dědičnost a používají ji třeba i na to, aby kód neměli duplicitní.

Dědičnost vznikla jako prostředek k odstranění duplicity kódu, jinak byste musel všechny specializované třídy řešit téměř kompletním přepisem. Jde to, ale porušuje to DRY, přidělává práci a je náchylné k chybám. (Pro rýpaly: Delegování dědičnost nenahrazuje, protože funguje jinak.)
Později ji začaly některé jazyky (s typovým polymorfismem - Java, ...) používat pro dosažení polymorfismu.

Chápu ještě využití polymorfismu, ale to není až tak časté.

Polymorfismus je jen nástrojem, je logické, že když jej vývojáři nezvládají, tak se s ním nesetkáte.

Ale celkově to moc dnes nedává smysl...

Jak to myslíte? Ono se něco změnilo?

[Ondra Satai Nekola]

Používáte dnes v OOP často dědičnost? Není ta doba už pryč?

Dědičnost nemá co dělat s dobou či módou, je to technologická záležitost! Podle módy programují lempli.

To je moc hezka teorie. Ale i kdyz jsi byl machr pred dvaceti lety, tak jsi proste programoval jinak nez machr dneska. A neni to zdaleka jenom tim, ze machr dneska ma k ruce jine IDE a jine jazyky.

Pokud tomu nechces rikat "moda", tak zkus trebas neutralnejsi "kultura".

[Kit]

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.

Někdo ještě používá protected atributy? Měly by být všechny privátní.

[SB]

... Prostě třeba před 20 lety to bylo celkem cool a dost se to používalo. Dnes se ví, že dědičnost je spíše zlo, tak jsem chtěl vědět, jestli pro ní někdo nemá nějaké nové a dobré využítí.

Znovu: Dědičnost není věcí módy, použití dědičnosti je v OOP poměrně přesně určeno, podstata a využití je stále stejné.

Máme plno nových jazyků a přístupů, takže všechno se dost mění.

Buďte klidný, na podstatě a účelu OOP se nic nezměnilo.

Utility class je také zlo, ne?

To je taková ta funkční třída? To je pochopitelně koncepční chyba, protože její metody patří jinam, ale někdy se jí nedá vyhnout vzhedem k chybějící funkcionalitě existujících tříd.

Tak jasný, v patternech je jí plno, ale je otázkou, jestli jsou ty patterny dnes dobré.

Některé vzory jsou poplatné jazykům, pro které vznikly, ale obecně dokud se nemění principy, vzory zůstávají.

[SB]

Problém je používání pevných typů namísto rozhraní. K tomu dědičnost svádí.

Jak může dědičnost svádět k záměně za rozhraní???

[SB]

Jestli používáš OOP a nepoužíváš dědičnost, tak tvoje znalost OOP busí být opravdu bídná.

Jsou objektové jazyky, ve kterých se bez dědičnosti obejdete, nebo které ji nemají.

[Tomáš Roll]

Jestli používáš OOP a nepoužíváš dědičnost, tak tvoje znalost OOP busí být opravdu bídná.

Jsou objektové jazyky, ve kterých se bez dědičnosti obejdete, nebo které ji nemají.

A taky existuje Brainfuck

[SB]

V některých jazycích je dědičnost takové "nutné zlo", ale dá se jí vyhnout (a je to žádoucí), viz např. Go. Pokud někdo "miluje" dědičnost, není moc dobrý vývojář.
Např. v Javě jsou knihovny dost mizerně navržené, takže se všude dědí, naopak např. v ObjC (Cocoa) se používají převážně rozhraní a shluky tříd, což je mnohem lepší v mnoha ohledech (dědičnost je jen u tříd pro GUI a měnitelných kolekcích).

On obecně vývojář, který má citový vztah k technologiím, asi nebude v pořádku.
Jak nahrazuje rozhraní dědičnost?

[karel]

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.

Někdo ještě používá protected atributy? Měly by být všechny privátní.

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í.

[SB]

...Osobne riesim duplicitu kodu bud delegaciou, alebo worker objectom, teraz k tomu pribudli aj funkcie...

Jak se řeší vnitřní funkcionalita objektu delegací, workerem či funkcí?