Dědičnost dnes

balki

Re:Dědičnost dnes
« Odpověď #210 kdy: 20. 01. 2017, 11:14:52 »
Pekne ste to povedali, ale ani prd vam nerozumiem a to mam takmer doktorat.
Doktorát z čeho? Historie "starých Slováků"? Podle toho, jak tu trolíš, nemáš ani základku a někde v Horních Uhrách se opíráš o lopatu a v jednom kuse nasáváš borovičku. Tak nás všechny ušetř těch kravin a dej si odchod.

Bez urážek!
Pan Balki si může veškeré uvedené termíny dohledat.

Mam sa ohlasit na sekretariate ceskej drevarskej univerzity v humpolci?


Re:Dědičnost dnes
« Odpověď #211 kdy: 20. 01. 2017, 11:21:40 »
Jinak by treba neplatila posloupnost

b = obdelnik.obsah()/obdelnik.a()
obdelnik.setSideA(10)
obdelnik.obsah() == b * obdelnik.a()

coz muze prekvapit a potrapit.

Aj! Však je to taky ze své podstaty totálně špatně! "B", "A" i obsah jsou vlastnosti objektu, které máte získávat od něj. A ne si je počítat bokem vedle. Vždyť jste tu předvedl naprosto flagrantní porušení zapouzdření!

Nicméně zařazuji do své sbírky odstrašujících příkladů.  :)

Nějaký podobný kód může být snadno součástí property based testů pro obdélník.
Ty by pochopitelně měly pricházet i pro podtřídy.


stryko sam

Re:Dědičnost dnes
« Odpověď #212 kdy: 20. 01. 2017, 11:22:48 »
Cele je to zase len umely problem.

Kód: [Vybrat]
class Shape extends React.Component
{
  get style()
  {
    return { backgroundColor: this.props.fillColor };
  }

  render()
  {
    return (
      <div className="Shape" style={this.style} />
    )
  }
}

class Square extends Shape
{
  get style()
  {
    return {
    ...super.style,
        width: this.props.a,
        height: this.props.a
    };
  }
}

class Rectangle extends Shape
{
  get style()
  {
    return {
    ...super.style,
        width: this.props.a,
        height: this.props.b
    };
  }
}

ReactDOM.render(<div>
  <Rectangle a={150} b={180} fillColor="red" />
  <Square a={150} fillColor="green" />
</div>, document.getElementById("Container"));

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #213 kdy: 20. 01. 2017, 11:44:34 »
[...] Rozhodující je, zda chcete čtverec modelovat pomocí obdélníku, nebo ne. Není důvod, aby to nešlo.
Jedním řešením vámi uvedeným je rozhraní. U jazyků bez podtypového polymorfismu se nepoužívá.
Jak "rozdělení funkcí do rozhraní" vede ke sdílenému kódu??? Rozhraní z podstaty věci žádný kód neobsahuje.

Triviálně:
Kód: [Vybrat]
protocol Parallelogram { /* declarations of properties */ }
extension Parallelogram {
  var area:Double { return cos(angle) * sideA * sideB }
}

Pokud to jazyk neumožní takto elegantně, tak např. v Go prostě
Kód: [Vybrat]
func Area(p Parallelogram) float64 { return ... }
Důležité je, že se pracuje jen s rozhraním. Jak třídy od sebe dědí je fuk, ostatně v tomto případě by to měly být beztak hodnotové typy, kde dědičnost není vůbec, ale to je už jiný problém.

gll

Re:Dědičnost dnes
« Odpověď #214 kdy: 20. 01. 2017, 12:07:40 »
Čet sis tu stránku na wikipedii (teď navíc nehodnotím jak je wikipedia autoritativní zdroj, zvlášť odstavec plný odkazů "citation needed")? Mixin je v zásadě trochu jiný princip než dědění i když se často pomocí dědění implementuje. Dálší je private dědičnost v C++, která je ale z principu rozbitá a rozhodně nedoporučuju to používat (přetypuješ na předka a můžeš volat privatní zděděné metody). A v celém tom odstavci popisujou antipattern fragile base class, ke kterému právě code reuse pomocí dědičnosti často vede. Zkus teda ukázat nějaký příklad použití, který je dobře. Celá tahle diskuze je o tom, že vždycky se řekne, to bylo špatně použité, ale ještě jsem neviděl příklad toho dobrého použití.

Kdo ohodnotí, jestli je to dobře? Nepsal jsem o c++, ale o pythonu. Tam se to používá. Privátní metody tam neexistují.


Kiwi

Re:Dědičnost dnes
« Odpověď #215 kdy: 20. 01. 2017, 12:17:40 »
Já teda očekávám, že program dělá jen věci které jsou v něm jasně napsané a ne věci o kterých se nikde nezmiňuje. Tak jsem asi špatný programátor a dávám do svých programů málo matematických chytáků.

1. To je přece naprosté nepochopení principu zapouzdření a blackboxu.
2. Právě proto dříve k programování takové jedince, kterým dělá potíže rozdíl mezi implikací a ekvivalencí a výrok "pro všechna X platí" znegují jako "pro žádné X neplatí", raději vůbec nepouštěli. A dělali dobře, jak je vidět.
Při vší úctě, jestli toto někdo považuje za matematický chyták, tak má raději někde tahat kabely po barácích, ale rozhodně by ho neměli pouštět k profesionálnímu programování! Tam akorát nadělá víc škody než užitku.

Ale no tak. Kód se píše pro lidi a pokud setA má neočekávané vedlejší efekty na b a odpálí navíc jaderné hlavice, je to očividně špatný návrh.

Jenže tady se nebavíme o tom, že by objekt obdélník, resp. čtverec odpaloval jaderné hlavice, ale o tom, že nějak reaguje na žádost o modifikaci nějaké své vlastnosti. Zasláním zprávy objektu tento objekt o něco požádáme. Jak se s tím vypořádá je interní věcí toho objektu. Že taková žádost může mít dopad i na jiné vlastnosti toho objektu by mělo být každému jasné. Jediné, co zde mohu očekávat, je to, že po poslání zprávy, jež má za cíl měnit vlastnosti toho objektu, nemohu spoléhat na jeho stav před zasláním této zprávy. Zajímají-li vás rozměry objektu obdélník, zeptejte se na ně toho obdélníku, protože ten jediný je relevantním zdrojem takové informace. Nikdo o nich totiž neví víc, než on sám.

Tady, jak tak koukám, narážíme na nepochopení samotné podstaty a základů objektového návrhu.

Prosil bych nejaky odkaz. Jestlize zmena strany u obdelnika *obecne* znamena, ze se druhy rozmer necha jak byl (a to je zcela rozumne ocekavani), proc by to u ctverce (ktery je take obdelnikem, kdyz jsme to takhle "chytre" nadefinovali) melo byt jinak.

Jaký odkaz, pro boha? Odkaz na co? Někteří lidé už jsou tak zblblí, že potřebují i odkaz na tvrzení, že jedna a jedna jsou dvě, nebo že s největší pravděpodobností slunce vyjde i zítra.
Změna strany obdélníka obecně právě neznamená, že se druhá strana nechá být! Ono to dokonce neznamená ani to, že se ta modifikovaná strana nastaví přesně dle přání žadatele. Ona se dokonce po takové zprávě nemusí změnit vůbec. Nebo může být nějak zlimitována nebo zaokrouhlena. V každém případě tam nebude hodnota, která tam byla poslána.

Pokud bude specifikováno, že posláním zprávy setSideA objektu obdélník se změní strana A a zároveň se zaručuje, že nedojde ke změně strany B, tak souhlasím s vámi se všemi. Ale pokud budu chtít odvozovat čtverec od obdélníka, tak nic takového do specifikace psát nebudu a pokud si to někdo domyslí sám ze své iniciativy, tak je s prominutím iniciativní hádejte co...

To neřeš. Tohle je očividně porušení kontraktu. Ať už někde popsaného ve specce, definovaného testy nebo očekávaného.

Ne! Tohle je velmi rozšířený nešvar, který se vždycky u studentů systematicky mýtil už od prvních semestrů technických a jiných exaktních vysokých škol, totiž naučit je, aby si nedomýšleli navíc nic, co není explicitně řečeno.  Když řeknu, že něco platí o nějaké reálné funkci jedné reálné proměnné, aniž bych někde explicitně řekl, že mám na mysli jen funkce spojité, tak v žádném případě nemohu očekávat, že se to jaksi tak nějak mimochodem určitě myslí. Kolik studentů na těchto "detailech" vyhořelo tak, že nakonec ty školy vůbec neudělali a díky tomu se naštěstí k žádnému programování prakticky nedostali...

Samozřejmě už vidím, jak mě nějaký místní "chytrák" chytá za slovo s tím, že ten obdélník by tak mohl teoreticky být i nějaký hyperkvádr, protože nikde není řečeno, že ty rozměry nemohou být komplexní, apod. Ale to je právě ten chybějící cit pro věc.
V každém případě, největší pohromou je, když si někdo domýšlí nad rámec toho, co bylo jasně specifikováno. Takže pan Ondra tu už fabuluje o porušení kontraktu (o němž neví zhola nic), specifikací (které si domyslel tak, aby měl pravdu) a chování testů (o nichž na základě zde padnuvších informací nemůže prohlásit nic). Opět nádherná ukázka naprosto chybného a nebezpečného stylu myšlení u programátora.

Inkvizitor

Re:Dědičnost dnes
« Odpověď #216 kdy: 20. 01. 2017, 12:44:18 »
Změna strany obdélníka obecně právě neznamená, že se druhá strana nechá být! Ono to dokonce neznamená ani to, že se ta modifikovaná strana nastaví přesně dle přání žadatele. Ona se dokonce po takové zprávě nemusí změnit vůbec. Nebo může být nějak zlimitována nebo zaokrouhlena. V každém případě tam nebude hodnota, která tam byla poslána.

Hm, aha, no jo. Tak se mejte hezky, soudruhu majore.

n

Re:Dědičnost dnes
« Odpověď #217 kdy: 20. 01. 2017, 12:53:25 »
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

Ne. Naopak u obecneho obdelniku PLATI, ze kolme strany k sobe jsou na sobe NEzavisle. Pokud tedy muzete delku stran menit(coz samozrejme nemusi jit) je dost pravdepodobne, ze zmena strany A neovlivni zmenu strany B. Pokud toto neplati, tak to je nejake specialni chovani. A nemodelujete obdelnik ale obdelnik se zavislyma stranama. Coz je nejaka konkretni specializace obdelniku, ktera se chove jinak, nez by je pro obdelnik mozne.
Vy si nejak definujete obdelnik matematicky, ale to je nedostatecna definice, protoze nemate definovano chovani(pokud neni immutable), jenom vysledny stav. V podstate definujete immutable objekt. Je to matematicke zjednoduseni. V realnem svete neexistuji v case nemenne objekty.
Vzhledem k vasem hloupemu vyjadreni o nematematicich bych mohl bych rict, ze to je prave problem matematiku, kteri stavi modely, ktere nepostihuji realitu, ale zjednoduseny model reality a proto matematik programator v realnych systemech nadela vic paseky nez uzitku. :-) Ale samozrejme je to nesmysl. Jen je treba si uvedomit, ze vase matematicka definice obdelniku neni definice obdelniku, ktery se v case muze menit.

n

Re:Dědičnost dnes
« Odpověď #218 kdy: 20. 01. 2017, 12:56:58 »
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

A zadruhe. Pokud ma setSideA() neocekavane vedlejsi efekty, tak to je chyba, ktera uz nema ani nic spolecneho s OOP, to je priklad poruseni zakladnich programovacich praktik(to bych se i zdrahal nazvat best practices), protoze za to by vam dali za usi uz v predemetu programovani na zakladce.

gll

Re:Dědičnost dnes
« Odpověď #219 kdy: 20. 01. 2017, 13:02:32 »
Čet sis tu stránku na wikipedii (teď navíc nehodnotím jak je wikipedia autoritativní zdroj, zvlášť odstavec plný odkazů "citation needed")? Mixin je v zásadě trochu jiný princip než dědění i když se často pomocí dědění implementuje. Dálší je private dědičnost v C++, která je ale z principu rozbitá a rozhodně nedoporučuju to používat (přetypuješ na předka a můžeš volat privatní zděděné metody). A v celém tom odstavci popisujou antipattern fragile base class, ke kterému právě code reuse pomocí dědičnosti často vede. Zkus teda ukázat nějaký příklad použití, který je dobře. Celá tahle diskuze je o tom, že vždycky se řekne, to bylo špatně použité, ale ještě jsem neviděl příklad toho dobrého použití.

Kdo ohodnotí, jestli je to dobře? Nepsal jsem o c++, ale o pythonu. Tam se to používá. Privátní metody tam neexistují.

ještě příklady z použití mixinů v ORM:

https://gist.github.com/YukSeungChan/851967b04d1f7cb6ba56
http://docs.sqlalchemy.org/en/latest/orm/extensions/declarative/mixins.html
https://gist.github.com/techniq/5174410

pomocí mixinů se dají například definovat sloupce opakující se ve více tabulkách.

n

Re:Dědičnost dnes
« Odpověď #220 kdy: 20. 01. 2017, 13:07:17 »
Změna strany obdélníka obecně právě neznamená, že se druhá strana nechá být! Ono to dokonce neznamená ani to, že se ta modifikovaná strana nastaví přesně dle přání žadatele. Ona se dokonce po takové zprávě nemusí změnit vůbec. Nebo může být nějak zlimitována nebo zaokrouhlena. V každém případě tam nebude hodnota, která tam byla poslána.

ROFL. "Zmena strany obdelnika... ...se nemusi zmenit vubec." =>Takze to neni zmena. Takze setA udela NIC. => Taky byste mohl predpoklada, ze 3 krat 3 rovna se bagr. Protoze prece nebudete neco predpokladat.

 Doufam, ze se nezivite programovanim. Pokud se zivite jeho ucenim, tak to je hodne spatny (v tom pripade byste mel mozna rict, kde ucite, pokud to tak je, aby se pripadni programatori vyhli vasi skole. Pripadne koho se mam u pohovoru ptat, jestli jste ho nahodou neucil, abychom neztraceli zbytecne cas).

javaman ()

Re:Dědičnost dnes
« Odpověď #221 kdy: 20. 01. 2017, 13:07:30 »
Kdyz budu mit mutable obdelnik s metodami setSideA a setSideB, ocekavam, ze kdyz zavolam setSideA, strana B se nezmeni, to je, rekl bych, pomerne dost ocekavana vlastnost. Jinak by treba neplatila posloupnost

Právě jste tu krásně ilustroval chybné myšlenkové pochody. Vy nemáte co očekávat to, co očekáváte, neboť to z ničeho nevyplývá! Vy máte očekávat jen to, že setSideA nastaví stranu A. O straně B se nic netvrdí, takže v souvislosti s setSideA nemáte o ní co očekávat. O straně B si jen chybně domýšlíte něco, co nikde není řečeno.

Bez urážky, ale tipuji, že matematika není vaším šálkem kávy. A toto je krásná demonstrace vhodnosti matematického vzdělání a matematického myšlení u programátorů, protože každého, kdo byl zmasírován matematikou, vaše "očekávání" nutně okamžitě udeří do očí, jelikož jde o typickou začátečnickou (resp. "zdravo-lidsko-rozumovou") chybu záměny implikace a ekvivalence.

A zadruhe. Pokud ma setSideA() neocekavane vedlejsi efekty, tak to je chyba, ktera uz nema ani nic spolecneho s OOP, to je priklad poruseni zakladnich programovacich praktik(to bych se i zdrahal nazvat best practices), protoze za to by vam dali za usi uz v predemetu programovani na zakladce.

Přesně tak.

Kiwi povídá píčoviny. Asi zažil první semestr na škole a je z toho úplně mimo ;D S matikou ty jeho nesmysly nemají nic společného. Na hloupé kamarády to ale v hospodě dojem udělat může 8)

gll

Re:Dědičnost dnes
« Odpověď #222 kdy: 20. 01. 2017, 13:50:31 »
Změna strany obdélníka obecně právě neznamená, že se druhá strana nechá být! Ono to dokonce neznamená ani to, že se ta modifikovaná strana nastaví přesně dle přání žadatele. Ona se dokonce po takové zprávě nemusí změnit vůbec. Nebo může být nějak zlimitována nebo zaokrouhlena. V každém případě tam nebude hodnota, která tam byla poslána.

ROFL. "Zmena strany obdelnika... ...se nemusi zmenit vubec." =>Takze to neni zmena. Takze setA udela NIC. => Taky byste mohl predpoklada, ze 3 krat 3 rovna se bagr. Protoze prece nebudete neco predpokladat.

 Doufam, ze se nezivite programovanim. Pokud se zivite jeho ucenim, tak to je hodne spatny (v tom pripade byste mel mozna rict, kde ucite, pokud to tak je, aby se pripadni programatori vyhli vasi skole. Pripadne koho se mam u pohovoru ptat, jestli jste ho nahodou neucil, abychom neztraceli zbytecne cas).

Kiwi má pravdu. Vy se odvoláváte na nějaké konvence, které nemusí platit všude.

SB

Re:Dědičnost dnes
« Odpověď #223 kdy: 20. 01. 2017, 15:07:41 »
Třída není realizátorem zapouzdření, tím je viditelnost metod a vlastností. Třída je realizátorem vytváření objektů.

Nejsem si jisty, co tim chces rict. Co ja chci rict je, ze zapouzdreni lze treba v Jave realizovat dvema zpusoby - viditelnosti v ramci tridy a viditelnosti v ramci modulu (package). Ale k cemu je dobre mit dve varianty stejne abstrakce? Nestacil by na to jen modul? Je to proste neortogonalni navrh jazyka.

Že to s třídou nemá co dělat - klidně můžete mít prototypovaný jazyk, který má u metod uvedenu viditelnost.
Jen pro modul je nedostatečná, základní stavební jednotkou jsou objekty. Smalltalk to má jednoduché - vlastnosti protected, metody public, v Squeaku/Pharu i určené metody protected.

Takze v pripade dedeni dat je to opacne, nez pises - tam se prave vyhneme polymorfismu... ...naopak pri dedeni interfacu, coz je zpusob polymorfismu, tenhle problem nevznika.

Nevím, zda má smysl řešit odděleně dědění vlastností a metod, když jsou neoddělitelné.

SB

Re:Dědičnost dnes
« Odpověď #224 kdy: 20. 01. 2017, 15:16:49 »
Aj pod pojmom OOP dnes ludia chapu skor objektovy model z C++, Javy a C# a malokto z beznych programatorov vobec vie o nejakom Smalltalku alebo posielani sprav.

Jen pro zajímavost: Aby se jazyky jako Smalltalk distancovaly od vámi uvedených hybridních jazyků, které si původní termín OOP přivlastnily, a jejich pojetí OOP, někteří pro ně používají termín čistě objektové jazyky (pure object languages). To myslím vypovídá o mnohém.