Omezená dědičnost (je něco lepšího než OOP?)

stud

Omezená dědičnost (je něco lepšího než OOP?)
« kdy: 31. 08. 2015, 14:43:30 »
Řekněme, že chci mít objekty čtverec, obdélník, kosočtverec a rovnoběžník. Je jasné, že s jednoduchou dědičností se daleko nedostanu. Proto obecný dotaz: existuje nějaké jiné paradigma, ve kterém lze vztahy mezi objekty vyjádřit lépe? Pokud ano, na jaký jazyk bych se měl podívat?


Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #1 kdy: 31. 08. 2015, 14:55:18 »
A co s nimi chces delat? Odpoved se nejspis bude lisit podle toho, zda je budes malovat nebo trebas pocitat obsahy...

Filip Jirsák nepřihlášený

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #2 kdy: 31. 08. 2015, 15:06:29 »
Myslíte vícenásobnou dědičnost? Ta je běžnou součástí OOP…

Kit

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #3 kdy: 31. 08. 2015, 15:07:04 »
Řekněme, že chci mít objekty čtverec, obdélník, kosočtverec a rovnoběžník. Je jasné, že s jednoduchou dědičností se daleko nedostanu. Proto obecný dotaz: existuje nějaké jiné paradigma, ve kterém lze vztahy mezi objekty vyjádřit lépe? Pokud ano, na jaký jazyk bych se měl podívat?

To je jednoduché: Všechny mají společného předka, kterého můžeme pojmenovat třeba Obrazec. Tento předek by měl být abstraktním.

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #4 kdy: 31. 08. 2015, 15:12:53 »
Řekněme, že chci mít objekty čtverec, obdélník, kosočtverec a rovnoběžník. Je jasné, že s jednoduchou dědičností se daleko nedostanu. Proto obecný dotaz: existuje nějaké jiné paradigma, ve kterém lze vztahy mezi objekty vyjádřit lépe? Pokud ano, na jaký jazyk bych se měl podívat?

To je jednoduché: Všechny mají společného předka, kterého můžeme pojmenovat třeba Obrazec. Tento předek by měl být abstraktním.

A jak takhle bez kontextu vis, ze to ma byt predek nebo protokol/interface?


k

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #5 kdy: 31. 08. 2015, 15:14:33 »
Bez znalosti požadovaných vztahů mezi objekty těžko nalezneme odpověď.

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #6 kdy: 31. 08. 2015, 15:18:46 »
Ajajaj.

Takže 3
2
1

fčíl!

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #7 kdy: 31. 08. 2015, 15:20:03 »
Alternativa je zamyslet se trebas nad alebraickymi datovymi typy. Ale na to neni "spravna" odpoved bez dalsich informaci (a dost mozna i s nimi).

Kit

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #8 kdy: 31. 08. 2015, 15:21:40 »
To je jednoduché: Všechny mají společného předka, kterého můžeme pojmenovat třeba Obrazec. Tento předek by měl být abstraktním.

A jak takhle bez kontextu vis, ze to ma byt predek nebo protokol/interface?

To je opět jednoduché: Odpověděl jsem v kontextu dotazu. Tazatel chtěl dědičnost, poskytl jsem mu společného předka. Pokud tazatel zkoriguje dotaz, mohu zkorigovat odpověď - stejně jako v TDD.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #9 kdy: 31. 08. 2015, 15:25:23 »
Short answer: Protocol-oriented programming: http://babel.blog.root.cz/2015/08/25/post-oop/

Long answer: Koncepční vztahy se deklarují pomocí protokolů. Např. každý tenzor je matice (ale ne naopak), každý vektor je tenzor a každý skalár je taky tenzor - jenže skalár je normální double (nebo komplexní číslo) a to už každý jazyk má a nedá se jim "podstrčit" nějaká nadtřída. Dá se ale říct, že vyhovují nějakému protokolu (a dodefinovat příslušné metody, např. pro derivaci tenzorových polí). Druhou výhodou je, že pak lze použít hodnotové typy, které z principu netvoří hierarchie (na rozdíl od tříd), ale zase program zrychlují. Sečteno a podtrženo: dědičnosti je lepší se úplně vyhnout.

Kit

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #10 kdy: 31. 08. 2015, 15:27:52 »
Bez znalosti požadovaných vztahů mezi objekty těžko nalezneme odpověď.

Jaké vztahy na tom chceš hledat? Chceš mi snad tvrdit, že čtverec je obdélník, lichoběžník nebo kosočtverec? Nebo že čtverec obdélník, lichoběžník nebo kosočtverec? Nic z toho není pravda, nemůžeš tedy použít ani dědičnost, ani kompozici.

Jsou to samostatné třídy, které mohou mít společného předka (např. Obrazec) nebo chceš-li rozhraní (např. Zobrazitelný).

Radek Miček

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #11 kdy: 31. 08. 2015, 15:30:12 »
Bez znalosti požadovaných vztahů mezi objekty těžko nalezneme odpověď.

Jaké vztahy na tom chceš hledat? Chceš mi snad tvrdit, že čtverec je obdélník, lichoběžník nebo kosočtverec? Nebo že čtverec obdélník, lichoběžník nebo kosočtverec? Nic z toho není pravda, nemůžeš tedy použít ani dědičnost, ani kompozici.

Jsou to samostatné třídy, které mohou mít společného předka (např. Obrazec) nebo chceš-li rozhraní (např. Zobrazitelný).

Každý čtverec je obdélník.

Kit

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #12 kdy: 31. 08. 2015, 15:31:17 »
Short answer: Protocol-oriented programming: http://babel.blog.root.cz/2015/08/25/post-oop/

Long answer: Koncepční vztahy se deklarují pomocí protokolů. Např. každý tenzor je matice (ale ne naopak), každý vektor je tenzor a každý skalár je taky tenzor - jenže skalár je normální double (nebo komplexní číslo) a to už každý jazyk má a nedá se jim "podstrčit" nějaká nadtřída. Dá se ale říct, že vyhovují nějakému protokolu (a dodefinovat příslušné metody, např. pro derivaci tenzorových polí). Druhou výhodou je, že pak lze použít hodnotové typy, které z principu netvoří hierarchie (na rozdíl od tříd), ale zase program zrychlují. Sečteno a podtrženo: dědičnosti je lepší se úplně vyhnout.

Perfekní rozbor, ale bohužel chybný závěr. Hodnotové typy do OOP nepatří. Jsou tam jen proto, že je programátoři chtěli.

Kit

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #13 kdy: 31. 08. 2015, 15:34:09 »
Každý čtverec je obdélník.

Není - on tak jen vypadá. Čtverec má jeden atribut, obdélník má dva. 1 != 2.

perceptron

Re:Omezená dědičnost (je něco lepšího než OOP?)
« Odpověď #14 kdy: 31. 08. 2015, 15:35:48 »
stvorec extends obdlznik je standardny fail lebo liskov substitutuion principle