Dědičnost dnes

lojzik

Re:Dědičnost dnes
« Odpověď #120 kdy: 18. 01. 2017, 06:36:17 »
Když už jsme u toho dědění, :) čtverec i obdélník jsou zvláštním případem pravidelného čtyřúhelníku, kde např. plocha se vypočítá jako základna * výška a u obou dochází k tomu, že výška splývá s druhou stranou.
no, on je čtverec i speciálním případem pravidelného mnohoúhelníku (s n=4), což už je ale úplně jiný strom dědičnosti, ve kterém žádný jiný čtyřúhelník není


noef

  • *****
  • 897
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #121 kdy: 18. 01. 2017, 07:25:03 »
Já tady jako jediný nebudu říkat, jestli čtverec dědí odbelník nebo ne - to totiž vůbec není nějak předem dáno. Prostě není. Čtverec dědí v naší aplikaci obdelník - a říkám v naší aplikaci, protože v reálném světě takovéhle sračky neřešíme - právě v případě, kdy to SPLŇUJE ÚČEL. Není žádné apripori sračka pravidlo (díky bohu), jestli čtverec dědí obdelník, ikdyž je čtverec brán jako případ obdelníku.

Tohle je ten pristup nahodneho dedeni pro deduplikaci kodu, ze? Zmeni se jeden detail a cela hierarchie trid se musi zahodit/prekopat, protoze to nikdy nebylo logicky navrzeno.

Někdo totiž může říct, že obdelník může být speciální případ cltverce. Máš čtverec, hodíš na něj botu a je z něho obdelník.

Kd říká že je to tak či onak, sám je nerozumí OOP, viz Zboj.

Zboj alespon pusobi, na rozdil od vetsiny, ze ma i nejaky teoreticky background a prehled o jinych jazycich nez jen Java/C#.

BTW: Dedeni obecne samo o sobe neimplikuje sub-typing ("is-a" vazbu) a pokud vim, tak je mozne v potomcich cleny i odebirat, takze pomoci obecneho dedeni lze modelovat i ten ctverec<->obdelnik jakymkoliv smerem bez zbytecnych clenu (pochopitelne to pak nesplnuje LSP, pokud se teda napouziji nejake interfacy spolecne pro obe tridy).

liewyec

Re:Dědičnost dnes
« Odpověď #122 kdy: 18. 01. 2017, 09:06:11 »
Spis vidim problem v dedicnosti v tom, ze misto aby se definovalo rozhrani tridy (v gui treba nastaveni barvy, velikosti, atd.) a to se pak pouzilo pro upravovani objektu(s tim ze by trida dedila interface ciste pro definovani funkci spolecnych pro pribuzne tridy(zase v gui treba render), tak jsou nekteri "experti" schopni pouzivat dedicnost tak, ze misto toho majidefinovanou funkci ktera ma za parametr odkaz data, ze kterych si ta trida ty informace ziska. Takze pokud pak potrebuji z tech dat ziskat neco jineho tak pouziji dedicnost a predefinuji funkci, ketere se pradava odkaz na data. Pak maji spoustu trid, ktere jsou v podstate uplne stejne. Coz vede naopak k duplikaci kodu, duplikaci dat, spouste ptomku jedne zakladni tridy, debilne se s tim pracuje a ma to spoustu dalsich problemu.

SB

Re:Dědičnost dnes
« Odpověď #123 kdy: 18. 01. 2017, 09:28:15 »
...Smaltalk má objekt, a ty ho vždycky přetěžuješ - to je sice hezký, ale s tím poděděným chováním si zároveň podědil i všechny ty vztahy. Což u typovaného jazyka může bejt dost problém. Další problém je v tom, že čím delší linie, tím méně se člověku chce opravovat chybné chování předka. Což je trapné.

Pozor na ten termín "přetěžování", s OOP nesouvisí, měl jste na mysli "překrývání".
Vzhledem k tomu, že dědím z důvodu příbuznosti, zdědění vztahů je logické a nevadí. S typovostí jazyku souvislost nevidím.
Oprava předka opraví i dědice, to je přece žádoucí.

...druhak máš trait/mixin... Výhoda je v tom, že mohu opravdu jen použít existující chování a přidat ho jinam.

Mixin bych pochopil, ale trait zavání 1. funkcionálním programováním, které odděluje data a zpracování, což je v přesném protikladu k OOP, 2. anemickým datovým modelem. Chování je v OOP z dobrého důvodu pevně spojeno se stavy, jejich rozdělení tudíž nemá smysl.

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

Specializace platí, a to ve všem, tj. stavy i chování.
Většina vývojářů neumí ani pochopit OOP, budeme ho kvůli tomu rušit jako koncept na prd?

milan:1

Re:Dědičnost dnes
« Odpověď #124 kdy: 18. 01. 2017, 09:36:55 »
Citam tak tuto diskusiu a zaujala ma jedna vec. Co myslite pod pojmom "skladani"? Mozete uviest priklad prosim? Dakujem


SB

Re:Dědičnost dnes
« Odpověď #125 kdy: 18. 01. 2017, 09:40:30 »
...
Kód: [Vybrat]
Hrnek dědí Nádoba
Sklenice dědí Nádoba

Voda dědí Náplň
Hrách dědí Náplň

Nádoba agreguje Náplň
or.

Určitě je to k zamyšlení...
Otázkou je, proč zobecňovat hrnek a sklenici na nádobu, co s tím budu dělat.
Náplně jsou dle mě chybně, protože to, že něco do něčeho můžu dát, tomu ještě nedává nějaké vlastnosti, to je jakési specifické použití, takže zobecněním vody a hrachu určitě není náplň.

noef

  • *****
  • 897
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #126 kdy: 18. 01. 2017, 09:42:23 »
...
...druhak máš trait/mixin... Výhoda je v tom, že mohu opravdu jen použít existující chování a přidat ho jinam.

Mixin bych pochopil, ale trait zavání 1. funkcionálním programováním, které odděluje data a zpracování, což je v přesném protikladu k OOP, 2. anemickým datovým modelem. Chování je v OOP z dobrého důvodu pevně spojeno se stavy, jejich rozdělení tudíž nemá smysl.
...

Myslim, ze tohle pro traity napr. ve Scale neplati. Trait si muze urcit do ceho bude namixovan (v podstate interface "this") a muze obsahovat jak stav, tak zpracovani. Casto tak rozdeluji velke tridy do nekolika traitu (a souboru) kvuli prehlednosti.

Po pravde si myslim, ze pokud ve Scale jedete "vice FP", tak spise pouzivate case classy a traity maximalne jako rozhrani (z case class nelze dedit dalsi case class). Traity si myslim jsou vice uzitecne pro OOP nez FP, alespon ve Scale.

SB

Re:Dědičnost dnes
« Odpověď #127 kdy: 18. 01. 2017, 09:44:34 »
...protoze spoustu casu travite usilim navrhnout smysluplnou hierarchii, i kdyz to nema smysl.

Vždy můžete zůstat u placaté hierarchie, dědit ve vašem modelu nemusíte, akorát si musíte ujasnit, zda vám to práci přidá nebo ubere.

SB

Re:Dědičnost dnes
« Odpověď #128 kdy: 18. 01. 2017, 09:46:16 »
...Ctverec je specialni pripad obdelniku, ale opravdu od sebe nemohou dedit.

Platí vše, co pro obdélník, též pro čtverec?

SB

Re:Dědičnost dnes
« Odpověď #129 kdy: 18. 01. 2017, 09:50:12 »
Koukam, ze OOP sice deformuje mysleni, ale relacni pohled na vec ho dava do mixeru.

Z pohledu historie modelování v IT považuju OOP za alespoň částečnou nápravu myšlení, ale s mixérem souhlasím.

SB

Re:Dědičnost dnes
« Odpověď #130 kdy: 18. 01. 2017, 09:58:03 »
Dokonce existuje i knihovna pro C (http://libcello.org/, ale nemam zkusenost), ktera prinasi objekty a tady je link na knihu, kde se o tom pise: https://www.cs.rit.edu/~ats/books/ooc.pdf

Je jedno, zda jde o možnosti jazyku či knihovny, podstatné je, zda to zvládá klíčové vlastnosti OOP. Pak je to objektový jazyk (akorát s některými to jde jednodušeji).

SB

Re:Dědičnost dnes
« Odpověď #131 kdy: 18. 01. 2017, 10:29:00 »
S tím bych moc nesouhlasil. Objektové paradigma se dá realizovat různě...

Jasně, teď bychom se tu mohli hádat, co je to objekt. Nějaké minimum, pod které strukturu za objekt nepovažuju, tu je, pod to tomu nemá smysl říkat objektový jazyk. Mimochodem dědění mezi základní koncepty OOP nepatří.

...že na papíře v učebnicích to vždycky vypadá všechno krásně jasně, přehledně, elegantně, jakoby tam skoro nebyl žádný problém...

Nevypadá. Nepochopení OOP má původ 1. v nedostatku kvalitní literatury. 2. v příkladech na obskurních jazycích, ale to už se tu řešilo.

...většinu času netrávím implementací požadované funkcionality, ale přemýšlením, jak to do toho všeho vlastně zašroubovat, aniž bych to musel celé přepsat, nebo aniž bych to tam dobastloval stylem šroub zatlučený kombinačkami.

Když to nemůžu opravit, tak problém/sračku izoluju a vyřeším uvnitř jednoho objektu/třídy, což je typicky objektový přístup.

Základní antagonismus OOP spatřuji v tom, že bylo zamýšleno k zjednodušení a zpřehlednění programu, k usnadnění práce a k zamezení "prasení". Jenže toto vše více-méně funguje jen tehdy, když 80% práce udělá opravdový fachman a ostatní už to jen k sobě skládají (opět, viz Smalltalk nebo třeba COCOA). Pokud na tu zelenou louku přijde psát from scratch objektový program někdo průměrný nebo dokonce podprůměrný, efekt objektového návrhu bude přesně opačný.

S tím se dá souhlasit, prostě je třeba daný nástroj zvládnout.

SB

Re:Dědičnost dnes
« Odpověď #132 kdy: 18. 01. 2017, 10:35:09 »
To původní bylo vlastně velmi jednoduché, jen zprávy mezi objekty, bez ohledu na dědičnost. Celá ta současná diskuse o Javě apod. je pak dost zcestná a není ani tak o OOP, jako o omezeních imperetivních jazyků, na které byly naroubovány objekty a virtuální volání.

Ano, virtuální volání, to je z mého pohledu největší rozpor mezi původním OOP (pozdní vazba s přenesením odpovědnosti na cílový objekt) a dnešní implementací (časná vazba s rozhodováním zdrojového objektu řešená typovou kontrolou).

SB

Re:Dědičnost dnes
« Odpověď #133 kdy: 18. 01. 2017, 10:41:32 »
nejlepsi OOP jazyk je beztak C#. nevim co tady porad resite

Časná vazba, podtypový polymorfismus, dědičnost v třídách pouze na instanční straně, vynucené volání super v konstruktorech, implicitně nevirtuální metody (OOP pojem nevirtuální nezná, protože nedává smysl), poměrně komplikovaná syntraxe, porušení zapouzdření mezi instancemi téže třídy...

To pálím jen tak z hlavy...

SB

Re:Dědičnost dnes
« Odpověď #134 kdy: 18. 01. 2017, 10:42:48 »
je to blbost, všichni ví, že nejlepší je java

Java je to samé v bleděmodrém. Ta si může s Ckanálem podat ruku.