Dědičnost dnes

[phpmág]

Používáte dnes v OOP často dědičnost? Není ta doba už pryč? 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í. Chápu ještě využití polymorfismu, ale to není až tak časté. Ale celkově to moc dnes nedává smysl, tak jsem chěl vědět názory zdejších odborníků. Třeba Kit by mohl něco zajímavého přinést.

[Reklama]

[Lemming]

Nevím jak ty, ale já dělám architekturu programu tak aby dobře fungoval. Ne podle toho, co je zrovna v módě. Takže větu "Ale celkově to moc dnes nedává smysl..." nechápu.

Samozřejmě, i dědičnost se dá "zneužívat" a zpřístupňovat pomocí ní funkce, které by měly být spíš v utility class, ale to nic nemění na tom, že v některých patternech je velmi užitečná.

[phpmág]

Tak jsem to nemyslel. 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í. A jak moc se používá u kolegů. Máme plno nových jazyků a přístupů, takže všechno se dost mění.

Utility class je také zlo, ne? Tak jasný, v patternech je jí plno, ale je otázkou, jestli jsou ty patterny dnes dobré.

[Honza]

Prosím o jeden konkrétní příklad, kdy ta dědičnost nedává smysl,
díky.

[phpmág]

Třeba pro tu neduplikaci kódu. Dědičnost s tím nemá nic společného, ale lidi to používají jako takovou "úložnu" kódu

[Reklama]

[Honza]

Třeba pro tu neduplikaci kódu. Dědičnost s tím nemá nic společného, ale lidi to používají jako takovou "úložnu" kódu

to přece není konkrétní příklad... ukaž kód, nebo link na něj

[gll]

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

[anonym]

Používáte dnes v OOP často dědičnost? Není ta doba už pryč? 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í. Chápu ještě využití polymorfismu, ale to není až tak časté. Ale celkově to moc dnes nedává smysl, tak jsem chěl vědět názory zdejších odborníků. Třeba Kit by mohl něco zajímavého přinést.

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

[zboj]

Používáte dnes v OOP často dědičnost? Není ta doba už pryč? 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í. Chápu ještě využití polymorfismu, ale to není až tak časté. [...]

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

[phpmág]

Super, alespoň někdo to chápe. Přesně tak, pokud se bavím s někým, kdo ji má rád, tak obvykle zjistím, že vůbec nerozumí designu. Pak ten kód samozřejmě nejde číst a nedává smysl.

Co tedy navrhuješ pro duplicity? V Javě by to šlo třeba přes generika, ale to Go nemá? Teď nevím, moc ho neznám.

[Kit]

Dědičnost používám tam, kde se potřeba. Je nutné, aby byl splněn výrok "potomek" _je_ "rodič". Například Automobil je Vozidlo, Faktura je Doklad, Kvádr je Těleso apod. Zároveň musí být v programu možná zaměnitelnost potomka a rodiče. Pokud tato pravidla nejsou splněna, dědičnost nelze použít.

[zboj]

Super, alespoň někdo to chápe. Přesně tak, pokud se bavím s někým, kdo ji má rád, tak obvykle zjistím, že vůbec nerozumí designu. Pak ten kód samozřejmě nejde číst a nedává smysl.

Co tedy navrhuješ pro duplicity? V Javě by to šlo třeba přes generika, ale to Go nemá? Teď nevím, moc ho neznám.

Defaultní implementace u rozhraní. Go to ale nemá, musí se řešit funkcemi. Ono Go je obecně relativně low-level a hodně věcí tam elegantně napsat nejde.

[balki]

Používáte dnes v OOP často dědičnost? Není ta doba už pryč? 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í. Chápu ještě využití polymorfismu, ale to není až tak časté. Ale celkově to moc dnes nedává smysl, tak jsem chěl vědět názory zdejších odborníků. Třeba Kit by mohl něco zajímavého přinést.

Pouzitie dedicnosti na odstranenie duplicity kodu je fakt uchylnost, takym koderom treba nakopat zadok, zbytocne to zneprehladnuje kod a da sa to riesit aj inak

Dedicnost pouzivam vtedy, ked potrebujem pouzit polymorfizmus. Alebo ked mam niekolko objektov, ktore maju mat navonok rovnake spravanie a mozu byt lubovolne zamenitelne. (slovo objekt pouzivam zamerne, na dualizmus trieda-instancia sa moc nehram). Vyhybam sa hlbokym hierarchiam dedicnosti, ak nie som nuteny (napriklad nejakym frameworkom).

Dedicnost, je ozaj sikovna vec, len to netreba cpat vsade za kazdu cenu.

[jpu]

ak vynechame dedicnost, tak potom ako mozme rozpravat o OOP? Predsa dedicnost patri medzi zakladne prvky objektovo-orientovaneho vyvoja. To, ze to modne trendy pouzivaju, nemusi hned platit, ze to je aj spravne.

[Kamil Podlešák]

Používáte dnes v OOP často dědičnost? Není ta doba už pryč? 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í. Chápu ještě využití polymorfismu, ale to není až tak časté. Ale celkově to moc dnes nedává smysl, tak jsem chěl vědět názory zdejších odborníků. Třeba Kit by mohl něco zajímavého přinést.

Pouzitie dedicnosti na odstranenie duplicity kodu je fakt uchylnost, takym koderom treba nakopat zadok, zbytocne to zneprehladnuje kod a da sa to riesit aj inak

Já bych nebyl tak striktní - použití dědičnosti pro odstranění duplicity je v mnoha jazycích s tradičním OOP osmdesátých/devadesátých let (třeba Java) celkem v pohodě. Ale jenom pokud se jedná o čistě implementační záležitost (ideálně ani společný předek není veřejný). Problémy nastanou pokud někdo použije dědičnost jako součást API. To prakticky vždy znamená jámu do které někdo spadne...

Dedicnost pouzivam vtedy, ked potrebujem pouzit polymorfizmus.

Jenom pro úplnost: jsou jazyky kde je možný polymorfismus i bez dědičnosti.