Abstrakce u OOP

[Jiří Havel]

jak poznám, že tam patří?

Veřejnou dědičností se modelují vztahy is-a. O každém potomkovi by se mělo dát říct, že je zároveň předkem. Navíc to není podmínka postačující, ale jen nutná.
Takže do předka patří jen taková logika, kterou mají všichni potomci. Pokud dává smysl jen pro některé potomky, pak předek nejspíš není to pravé místo.

Příklad funkčnosti, která mi dává v předkovi smysl, je kontrola vstupů, návratových hodnot a invariantů.

Samozřejmě jako všechno u návrhu SW je to důsledné doporučení a nedá se tupě aplikovat vždycky a bez přemýšlení.

V poslední době se v některých jazycích rozšířili traity/mixiny, které jsou určeny právě na to reusable kódu. Protože sice do objektu přidávají logiku, kterou chceme, ale nepřidávají, že potomek JE předek.

Jop, tohle je dobrý příklad veřejné dědičnosti, která nemodeluje vztah JE. Typický je třeba Curously Recurring Template Pattern v C++ :

Kód: [Vybrat]

class Derived : public Base<Derived>
{
};
Předek není třída ale šablona, která potřebuje vědět typ potomka. Díky tomu se o vztahu JE vůbec nedá mluvit, protože ten předek sám o sobě není nějaká hotová věc.
Hodí se to třeba, pokud pro nějaká datová struktura potřebuje vestavěnou podporu ve vkládaných typech. Ta báze může třeba obsahovat ukazatele, aby se instance odvozené třídy daly strkat do spojového seznamu.

[Reklama]

[alex6bbc]

a vsecko tohle uz me na C++ pekne stve. kazdy primicha do kodu jinou metodologii a pak aby clovek umel vsecko.
proto zacinam pokukovat po Go, zas se neco zjednodusi a struktury s interface staci.

[Idris]

jak poznám, že tam patří?

Veřejnou dědičností se modelují vztahy is-a. O každém potomkovi by se mělo dát říct, že je zároveň předkem. Navíc to není podmínka postačující, ale jen nutná.
Takže do předka patří jen taková logika, kterou mají všichni potomci. Pokud dává smysl jen pro některé potomky, pak předek nejspíš není to pravé místo.

Příklad funkčnosti, která mi dává v předkovi smysl, je kontrola vstupů, návratových hodnot a invariantů.

Samozřejmě jako všechno u návrhu SW je to důsledné doporučení a nedá se tupě aplikovat vždycky a bez přemýšlení.

V poslední době se v některých jazycích rozšířili traity/mixiny, které jsou určeny právě na to reusable kódu. Protože sice do objektu přidávají logiku, kterou chceme, ale nepřidávají, že potomek JE předek.

Právě jsem je chtěl zmínit.

[Idris]

jak poznám, že tam patří?

Veřejnou dědičností se modelují vztahy is-a. O každém potomkovi by se mělo dát říct, že je zároveň předkem. Navíc to není podmínka postačující, ale jen nutná.
Takže do předka patří jen taková logika, kterou mají všichni potomci. Pokud dává smysl jen pro některé potomky, pak předek nejspíš není to pravé místo.

Příklad funkčnosti, která mi dává v předkovi smysl, je kontrola vstupů, návratových hodnot a invariantů.

Samozřejmě jako všechno u návrhu SW je to důsledné doporučení a nedá se tupě aplikovat vždycky a bez přemýšlení.

V poslední době se v některých jazycích rozšířili traity/mixiny, které jsou určeny právě na to reusable kódu. Protože sice do objektu přidávají logiku, kterou chceme, ale nepřidávají, že potomek JE předek.

Jop, tohle je dobrý příklad veřejné dědičnosti, která nemodeluje vztah JE. Typický je třeba Curously Recurring Template Pattern v C++ :

Kód: [Vybrat]

class Derived : public Base<Derived>
{
};
Předek není třída ale šablona, která potřebuje vědět typ potomka. Díky tomu se o vztahu JE vůbec nedá mluvit, protože ten předek sám o sobě není nějaká hotová věc.
Hodí se to třeba, pokud pro nějaká datová struktura potřebuje vestavěnou podporu ve vkládaných typech. Ta báze může třeba obsahovat ukazatele, aby se instance odvozené třídy daly strkat do spojového seznamu.

Tak C++ je vůbec divočina, tam je dědičnost tak mocná, že umožňuje psát higher kinded typy. Ne že by to tam bylo nějak zvlášť čitelné...

[Jiří Havel]

Tak C++ je vůbec divočina, tam je dědičnost tak mocná, že umožňuje psát higher kinded typy. Ne že by to tam bylo nějak zvlášť čitelné...

Jo, s čitelností je to horší. Šablony holt nebyly navržené pro tohle použití. Že jsou výpočetně úplné a co všechno se s nima dá udělat se zjistilo až dodatečně.

Naštěstí se spousta téhle divočiny dá udržet v implementaci knihoven. Samotné použití pak nevypadá až tak zle. A constexpr funkce a koncepty z C++20 tu čitelnost hodně zlepšují.

[Reklama]

[Ink]

a vsecko tohle uz me na C++ pekne stve. kazdy primicha do kodu jinou metodologii a pak aby clovek umel vsecko.
proto zacinam pokukovat po Go, zas se neco zjednodusi a struktury s interface staci.

Proč ne raději Rust? Výkonově srovnatelný s C++, podobné koncepty (RAII apod.)?

[Idris]

a vsecko tohle uz me na C++ pekne stve. kazdy primicha do kodu jinou metodologii a pak aby clovek umel vsecko.
proto zacinam pokukovat po Go, zas se neco zjednodusi a struktury s interface staci.

Proč ne raději Rust? Výkonově srovnatelný s C++, podobné koncepty (RAII apod.)?

Třeba kvůli gorutinám a kanálům.

[Ink]

a vsecko tohle uz me na C++ pekne stve. kazdy primicha do kodu jinou metodologii a pak aby clovek umel vsecko.
proto zacinam pokukovat po Go, zas se neco zjednodusi a struktury s interface staci.

Proč ne raději Rust? Výkonově srovnatelný s C++, podobné koncepty (RAII apod.)?

Třeba kvůli gorutinám a kanálům.

Tebe jsem se neptal, sorry.

[Kit]

Obrovskou výhodou správně použité dědičnosti je vzájemná zaměnitelnost předka s potomky. Když mi jeden potomek nevyhovuje, tak místo něj použiji jiného. Zbytku aplikace se to nijak nedotkne, nemusím nic přepisovat. V případě programování proti interface je to ještě jednodušší a čitelnější, odpadá problém diamantu.

[Standa Blábol]

Dedeni vs interface je evergreen a porad to hromada lidi nechape.

Pritom zakladni hruby mechanismus je prosty.
Kdyz potrebuju rozsirit funkcionalitu pri zachovani stavajici - dedeni.
Kdyz potrebuju pracovat stejnym zpusobem s ruznymi objekty s ruznou vnitrni implementaci - interface.

Udelat bazovou tridu a v ni pulku metod overloadovat je kokotina.

A nejvetsi zadek je, ze se to normalne ve skolach uci, viz:
https://stackoverflow.com/questions/50793617/object-oriented-design-shapes
Je uplna hovadina dedit shapes (rectangle, triangle, circle), kdyz se pak dilci metody (obsah, bod je uvnitr apod) stejne pro kazdy typ pocita jinak.
To je typicky priklad na interface.

Typicky priklad na dedeni je treba plugin, tam mam par overloadovaych metod typu init(), execute(), destroy(), zbyle metody potrebne pro komunikaci s okolnim frameworkem zustavaji jak jsou a casto jsou este oznackovany "final", aby vubec overloadovat nesly.

[Google CTCCTCGGCGGGCACGTAG]

Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.

casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.

pokusy o slovni popisy vyznamu kodu nefunguji.

[Kit]

Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.

casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.

pokusy o slovni popisy vyznamu kodu nefunguji.

Mixiny dělají akorát bordel v kódu. Snadno se píší, ale blbě se čtou. Přitom se dají jednoduše nahradit kompozicí.

[Ondrej Nemecek]

Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.

casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.

pokusy o slovni popisy vyznamu kodu nefunguji.

Že mixin není ani IS ani HAS ještě neznamená, že slovní popisy nefungují. Mixin je něco, co přimixuju a co mohu poměrně svobodně přimixovávat právě bez ohledu na to, co objekt IS nebo HAS.

[Google CTCCTCGGCGGGCACGTAG]

Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.

casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.

pokusy o slovni popisy vyznamu kodu nefunguji.

Mixiny dělají akorát bordel v kódu. Snadno se píší, ale blbě se čtou. Přitom se dají jednoduše nahradit kompozicí.

na mixinech jsou postavene nektere opravdu hodne uspesne knihovny. Me zajima, co se osvedcilo v praxi, ne co je "spatne" podle teoretiku v diskuzi. Jazykove konstrukty nemaji zadny filozoficky vyznam.

[Google CTCCTCGGCGGGCACGTAG]

Tak existuje klasické pravidlo, zda objekt IS nebo objekt HAS.

casto neni ani jedno, co treba mixiny? Je to dedeni, ale pouzivaji se treba pro pridavani atributu do trid.

pokusy o slovni popisy vyznamu kodu nefunguji.

Že mixin není ani IS ani HAS ještě neznamená, že slovní popisy nefungují. Mixin je něco, co přimixuju a co mohu poměrně svobodně přimixovávat právě bez ohledu na to, co objekt IS nebo HAS.

Slovni popisy nefunguji, protoze programy nepiseme v prirozenem jazyce.