Dědičnost dnes

SB

Re:Dědičnost dnes
« Odpověď #90 kdy: 17. 01. 2017, 13:44:27 »
...Např. GUI toolkity používají OOP již desítky let...Dokonce k tomu nepotřebují ani OO jazyk (GTK+)...

Buďto jazyk konstrukce OOP umí, pak umí vytvářet objekty a je objektový, nebo je neumí, pak to nejsou objekty. Co je na tom tak složitého?

...V těchto aplikacích má použití dědičnosti s hlubokou polymorfní hierarchií hodně dobrý smysl. Naopak mi není moc jasné, proč se data v informačním systému snažit modelovat pomocí objektů a následně se hádat o různé aspekty OOP, když by lépe posloužil relační databázový model. Zvlášť, když data jsou už často v relační databázi uložena.

Proč si myslíte, že vizuální komponenty jsou nějak vhodnější nebo lepší pro OOP než nevizuální? Nevyplývá to z původní popularizátorské představy, že když je něco vidět, tak je to objekt?
Jak zrealizujete v relačním modelu oddělení podproblému (v OOP řešeno zapouzdřením)? Odpovím si sám. Nijak. Relační model patří do skupiny modelů "kámen mrdá cihlu", tj. každý s každým, a to se ještě nebavíme o práci se seznamy.


v

Re:Dědičnost dnes
« Odpověď #91 kdy: 17. 01. 2017, 13:52:42 »
...Např. GUI toolkity používají OOP již desítky let...Dokonce k tomu nepotřebují ani OO jazyk (GTK+)...

Buďto jazyk konstrukce OOP umí, pak umí vytvářet objekty a je objektový, nebo je neumí, pak to nejsou objekty. Co je na tom tak složitého?
není to složité, OO jazyk a OO programování jsou různé věci a navzájem se nepotřebují, říct o C, že je objektový jazyk, by znělo přece jenom divně

bob

Re:Dědičnost dnes
« Odpověď #92 kdy: 17. 01. 2017, 13:58:41 »
není to složité, OO jazyk a OO programování jsou různé věci a navzájem se nepotřebují, říct o C, že je objektový jazyk, by znělo přece jenom divně

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

Nicmene je asi pohodlnejsi mit podporu OO primo v jazyce a ne si to hlidat sam nad strukturama.

Re:Dědičnost dnes
« Odpověď #93 kdy: 17. 01. 2017, 14:04:49 »
Proč si myslíte, že vizuální komponenty jsou nějak vhodnější nebo lepší pro OOP než nevizuální? Nevyplývá to z původní popularizátorské představy, že když je něco vidět, tak je to objekt?
Ne. Vizuální komponenty se uvádějí jako příklad úspěšné aplikace OOP z toho důvodu, že se tato kombinace reálně osvědčila a přinesla skutečné výsledky (ulehčení a zjednodušení práce, vyšší produktivitu).
Myslím že na to existují dokonce reálná data, ale ruku do ohně bych za to nedal.

Kiwi

Re:Dědičnost dnes
« Odpověď #94 kdy: 17. 01. 2017, 14:39:22 »
Buďto jazyk konstrukce OOP umí, pak umí vytvářet objekty a je objektový, nebo je neumí, pak to nejsou objekty. Co je na tom tak složitého?

S tím bych moc nesouhlasil. Objektové paradigma se dá realizovat různě - viz Java vs. Smalltalk vs. Common Lisp. "Objekt" je abstraktní pojem a jeho konkrétní implementace v tom kterém jazyce je věcí jinou. Nadto i ten abstraktní pojem znamená i v těch výše jmenovaných jazycích pokaždé něco trochu jiného. Objekt v pojetí CLOS se dost liší od Javy i Smalltalku, vlastně je to analogie prachsprostého záznamu a polymorfismu se dosahuje pomocí generických funkcí. Celé je to implementované "jen" v Common Lispu, tedy jazyku neobjektovém. Podobně se dá udělat objektová nadstavba třeba u Forthu. A jako protipříklad bych použil C++, jež sice objekty jakože umí, ale v mých očích to nikdy objektový jazyk nebyl (aby se předešlo různým flamům a nedorozuměním, tak předesílám, že pokud jde o OOP, tak jsem odkojenec Smalltalku).
Podobně např. Assembler je typický špagetový jazyk, ale je-li kompilátor vybaven dobrým makroprocesorem, dá se v něm solidně programovat i strukturovaně.
Takže s pomocí pár procedur a maker bych si asi dokázal napsat cosi, s čím bych mohl vyrábět objekty a programovat objektově i v normálním, neobjektovém C. Ostatně Objective C přesně takto začínalo a přitom jde o rozhodně víc objektový jazyk než C++ (opět v tomto místě raději připomínám svou vazbu na Smalltalk).

A pokud jde o pochopení/nepochopení dědění a jeho praktického používání, tak na základě svých celoživotních zkušeností to vidím zhruba tak, ž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. Ale když má člověk upravit cizí program, tak musím konstatovat, že myšlenkové pochody, jež vedly zrovna k takové konkrétní hierarchii tříd, jsou mi mnohdy velkou záhadou a logiku celého programu rozhodně neosvětlují, ale spíše zatemňují, a práci rozhodně nešetří, ale přidělávají, protože 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.

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


zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #95 kdy: 17. 01. 2017, 15:01:04 »
False.
OOP je o komunikačním grafu agentů.
Dědičnost je víceméně z nouze ctnost.
OOP prostě nejde ke statickému typování.

Agenty jako (chytré) instance nesouvisejí s konstrukcí tříd pro výrobu (hloupých) instancí.
Dědičnost je mechanismus pro odvozování podobných tříd.
Původní OOP nikdy statické nebylo, to vzniklo až jako hybridní, původně imperativní jazyky. Z toho jsou pak mylně odvozovány obecné vlastnosti OOP.
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í.

SB

Re:Dědičnost dnes
« Odpověď #96 kdy: 17. 01. 2017, 15:05:03 »
A není to spíše naopak? Že protected umožňuje horkotěžko vyladěné chování rodičovské třídy nabourat a znepřehlední flow života instance, namísto jednoduchého, přímočarého a hlavně dobře otestovatelného delegování?

Aby tu opět nedošlo k nějakému nedorozumění - kurvení podtřídy ovlivňuje pouze ji a její instance, nadtřídu nijak nabourat nelze.

Protected je ekvivalent public. A jak tu bylo řečeno, nese si problém s tím, že se jedná o veřejné api, které je nutné dodržet. Což zvyšuje komplexitu.

Specializaci, kterou byste místo překrýváním chtěl řešit opačnou závislostí, např. uzávěrami nebo vzorem Strategy, má taky nějaké rozhraní, které u nemůžete změnit, jak vás napadne, takže mi to přijde stejně složité.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #97 kdy: 17. 01. 2017, 15:06:35 »
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.
Někoho by mohlo v této souvislosti zajímat "protocol-oriented programming", což je velmi zajímavé a hlavně efektivní paradigma. V některých jazycích (např. Go) je v podstatě vynucováno a v jiných, které podporují přímo v syntaxi i OOP, umožňuje elegantnější (a lépe udržovatelný) zápis kódu. Navíc na rozdíl od OOP se dá dobře kombinovat s FP.

spasitel

Re:Dědičnost dnes
« Odpověď #98 kdy: 17. 01. 2017, 15:46:02 »
nejlepsi OOP jazyk je beztak C#. nevim co tady porad resite

Re:Dědičnost dnes
« Odpověď #99 kdy: 17. 01. 2017, 15:57:26 »
nejlepsi OOP jazyk je beztak C#. nevim co tady porad resite

Jako navnada na flame dost ubohe.

spasitel

Re:Dědičnost dnes
« Odpověď #100 kdy: 17. 01. 2017, 15:58:54 »
zadna navnada. jde o holy fakt a krutou pravdu.

v

Re:Dědičnost dnes
« Odpověď #101 kdy: 17. 01. 2017, 16:02:07 »
zadna navnada. jde o holy fakt a krutou pravdu.
je to blbost, všichni ví, že nejlepší je java

abc

Re:Dědičnost dnes
« Odpověď #102 kdy: 17. 01. 2017, 16:05:43 »
Je mi divne, ze tu chybi hlavni lopata... co se stalo?

phpmág

Re:Dědičnost dnes
« Odpověď #103 kdy: 17. 01. 2017, 16:26:27 »
A jak teda obecně řešit problém, kdy mám třeba 5 různých typů dat, které trochu spolu souvisí, ale dědičnost tam nejde použít přesně proto, co jsi napsal. 5 různých tříd nesdílejích nic? 5 různých služeb pracující s nimi? Nebo použít pro služby generickou službu? A co ukládání? Je to obecně složité téma, ale jen tak jestli máš nějaké tipy k tomu. Málo dat a hodně logiky je jednodušší, ale když jsou data, která je potřeba mít, tak se to komplikuje.

Co je to "trochu souvisejí"?
Jestli ty entity nemají spolu (skoro) nic společného, tak je přece nebudu modelovat dohromady, protože nemají co sdílet, pak budou extra, jejich zpracování jinde bude extra a i způsob ukládání bude extra. I entity, které mají hodně společného, je možno klidně modelovat extra, ale přiděláte si tím práci.

Že mají třeba 5 atributů stejných a dva jiné :) Takže jsou v podstatě stejné, ale "nedává" smysl je modelovat dohromady. Zase z hlediska údržby chce člověk mít co nejvíce společného. Pak přichází na řadu ukládání. Radši bych to ukládal úplně stejně pro obě. Ono každé má něco a chápu, že neexistuje jen jedno řešení.

Takže tvůj nápad je mít zvášť třídy, zvlášt služby a třeba zvlášť ukládání. Což bude asi docela dost duplicity. Pokud tomu dobře rozumím.

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.
Někoho by mohlo v této souvislosti zajímat "protocol-oriented programming", což je velmi zajímavé a hlavně efektivní paradigma. V některých jazycích (např. Go) je v podstatě vynucováno a v jiných, které podporují přímo v syntaxi i OOP, umožňuje elegantnější (a lépe udržovatelný) zápis kódu. Navíc na rozdíl od OOP se dá dobře kombinovat s FP.

Super, díky za info. Všechny příspěvky čtu, jen ne vždy reaguju.

Je mi divne, ze tu chybi hlavni lopata... co se stalo?

Asi nedostal vycházky :D

JS

Re:Dědičnost dnes
« Odpověď #104 kdy: 17. 01. 2017, 16:56:28 »
Puvodni Karel ma pravdu - OOP (jak se bezne chape, treba v Jave) micha tri koncepty dohromady (zapouzdreni, dedicnost, polymorfismus) do jednoho - trid. Je to omyl a zpetne to vidime. Konkretne, dedicnost dava smysl pro data, nikoli pro funkce, a naopak, polymorfismus dava smysl pro funkce, nikoli pro data. A potreba neco zapouzdrit jeste neznamena, ze musime vytvaret novy typ.

Treba Haskell (jako vetsina funkcionalnich jazyku) to ma rozdelene pomerne jasne. Zapouzdreni se realizuje pomoci modulu, dedicnost pomoci treba algebraickych typu (nebo obecne typu vyssiho radu) a polymorfismus pomoci typovych parametru a typovych trid.