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

[JSH]

Dokážu si představit že kompilátor místo dědičnosti a virtuálních metod jednoduše definice a kód všech proměnných a nevirtuálních metod zkopíruje z předka, dneska máme paměti dost. Problémy ale zůstanou stejné, změní se to jenom technicky.

Prosím, zapomeň na cokoliv co připomíná dědičnost. Pořádný code reuse znamená že stejný kód zvládne pracovat s věcmi co ani nikdy neležely ve stejném adresovém prostoru, natož aby se dalo mluvit o nějakém společném předkovi.

Protokoly o kterých tu mluví MP se se zatnutými zuby dají trochu přirovnat k abstraktním třídám, ale i tohle je zavádějící.

Typický nesmysl je místo pole int udělat kolekci s pointery na objekty Int, samozřejmě každý objekt má vlastní alokaci na haldě, aby zlo bylo maximální.

Tohle je jen bezvýznamná drobnost. Opravdové zlo leží někde jinde.

[Reklama]

[Logik]

Prýmek: To, jak odlišuješ dědičnost od toho, co je v GO, ale záleží na definici dědičnosti. Pokud do pojmu dědičnost zahrneš duck-typing, pak to, co je v GO splňuje definici dědičnosti - umí to kachní protokol, je to kachna. S tím, že to má všechny výhody a nevýhody duck-typingu - tj. objekty umí něco navíc, co s třídní dědičností nelze a platím za to horší možností syntaktické kontroly.

---

Code reuse samozřejmě neznamená jen dědičnost. Dědičnost je jedna z metod. A ten kdo umí dědičnost a neumí jiné metody bude obhajovat dědičnost, a kdo neumí dědičnost a umí jiné metody ji bude hanit. A oba se budou hádat, že "to druhé" je cesta do pekla. Dobrý programátor prostě použije vhodně daný kontext a max si zanadává - todle by šlo v támdletom jazyku napsat elegantnějc. Já takhle střídám několik jazyků a rozstu z toho dost.

---

"To je v problému čtvercoobdélník splněno Čtverec má dané metody obdélníka..."
Jak jsem již psal, to může a nemusí být pravda. Pokud obdélník nadefinuji jako něco, co umí změnit jednu stranu nezávisle na druhé, tak čtverec definici obdélníka prostě nesplňuje a dané metody mít nemůže.

[zboj]

Aby tu nebylo jen pusté filosofování, zde je "protocol-oriented" kód (ať to není příliš dlouhé, tak jen pro nejobecnější a nejspeciálnější případ):

Kód: [Vybrat]

protocol QuadrilateralWithParallelOppositeSides {
    var side1:Double { get }
    var side2:Double { get }
    var skew:Double { get }
}

extension QuadrilateralWithParallelOppositeSides {
    func area() -> Double {
        return side1 * side2 * cos(skew)
    }
}

struct Parallelogram : QuadrilateralWithParallelOppositeSides {
    var side1:Double
    var side2:Double
    var skew:Double
    init(side1 s1:Double, side2 s2:Double, skew s:Double) {
        side1 = s1
        side2 = s2
        skew = s
    }
}

struct Square : QuadrilateralWithParallelOppositeSides {
    var side1:Double
    var side2:Double { return side1 }
    var skew:Double { return 0 }
    init(side s1:Double) {
        side1 = s1
    }
}

let figure1 = Parallelogram(side1: 2, side2: 3, skew: M_PI_4)
let figure2 = Square(side: 3)
var list:Array<QuadrilateralWithParallelOppositeSides> = [ figure1, figure2 ]
print(list.map { $0.area() })

Jak je hezky vidět, metoda pro výpočet obsahu se definuje jen jednou. O různé invarianty se postarají "computed properties". Jednoduché, elegantní a rozšiřitelné

[Kit]

OOP je zlo ...  sposobuje neustale bobtnanie kodu a spomalovanie sa aplikacii ... Problem je uz v celkovej fylozofia OOP, abstrakcia, rozne VM, medzivrstvy, kniznice, frameworky a lepenie kodu.

Jak bys mi chtěl zdůvodnit, že dříve napsané aplikace, které jsem přepsal do OOP, se mi zkrátily a zrychlily? A podobně dopadají i cizí programy, které refaktoruji do OOP, abych do nich mohl začít dělat své modifikace.

Problémy s OOP nehledej v bobtnání kódu, abstrakci apod. Hledej je v chybně pochopeném OOP.

[JS]

Co se tyka OOP, dedicnosti a Go.. tady se dost zapomina, ze se dedi data, nikoli funkce (funkce neni treba dedit - bud jsou polymorfni nebo ne, a to je dane fakticky tim, jake jine funkce volaji (pripadne k jakym datum pristupuji ale to je jen specialni pripad volani)). Nejlepsi je IMHO se ke "klasickemu" OOP (C++, Java..) postavit tak, ze jde o tri ruzne abstrakce:

• Zapouzdreni
• Dedicnost
• Polymorfismus

Vsechny tyhle vlastnosti Go ma, ale misto toho, aby je michalo dohromady jako "tridy", tak je ma zvlast:

• Moduly
• V definici struktury je mozne primo vlozit jinou strukturu, bez kvalifikace (jenom jednu - odpovida jednonasobne dedicnosti)
• Interfacy (nebo tez protokoly - lze o objektu prohlasit, ze splnuje nejaky interface, napsat funkci, ktera predpoklada interface atd.)

IMHO je to tak lepsi. Mate tri ortogonalni koncepty a muzete si je smichat jak je libo.

[Reklama]

[Kit]

Aby tu nebylo jen pusté filosofování, zde je "protocol-oriented" kód (ať to není příliš dlouhé, tak jen pro nejobecnější a nejspeciálnější případ):

Kód: [Vybrat]

... Jak je hezky vidět, metoda pro výpočet obsahu se definuje jen jednou. O různé invarianty se postarají "computed properties". Jednoduché, elegantní a rozšiřitelné

Zdá se mi to, nebo ten příklad je ve skutečnosti zbytečně komplikovaný a má daleko k eleganci?

[zboj]

Co se tyka OOP, dedicnosti a Go.. tady se dost zapomina, ze se dedi data, nikoli funkce (funkce neni treba dedit - bud jsou polymorfni nebo ne, a to je dane fakticky tim, jake jine funkce volaji (pripadne k jakym datum pristupuji ale to je jen specialni pripad volani)). Nejlepsi je IMHO se ke "klasickemu" OOP (C++, Java..) postavit tak, ze jde o tri ruzne abstrakce:

• Zapouzdreni
• Dedicnost
• Polymorfismus

Vsechny tyhle vlastnosti Go ma, ale misto toho, aby je michalo dohromady jako "tridy", tak je ma zvlast:

• Moduly
• V definici struktury je mozne primo vlozit jinou strukturu, bez kvalifikace (jenom jednu - odpovida jednonasobne dedicnosti)
• Interfacy (nebo tez protokoly - lze o objektu prohlasit, ze splnuje nejaky interface, napsat funkci, ktera predpoklada interface atd.)

IMHO je to tak lepsi. Mate tri ortogonalni koncepty a muzete si je smichat jak je libo.

To "vkládání" struktur není moc rozumné, někdy má podtřída (díky invariantům, viz výše) méně dat než rodič.

[JSH]

Zdá se mi to, nebo ten příklad je ve skutečnosti zbytečně komplikovaný a má daleko k eleganci?

Já bych řekl, že je to vcelku elegantní. Maximálně trochu ukecané. Ale samozřejmě výpočet obsahu je moc jednoduchý problém na to, aby tam ta elegance vynikla.

[zboj]

Aby tu nebylo jen pusté filosofování, zde je "protocol-oriented" kód (ať to není příliš dlouhé, tak jen pro nejobecnější a nejspeciálnější případ):

Kód: [Vybrat]

... Jak je hezky vidět, metoda pro výpočet obsahu se definuje jen jednou. O různé invarianty se postarají "computed properties". Jednoduché, elegantní a rozšiřitelné

Zdá se mi to, nebo ten příklad je ve skutečnosti zbytečně komplikovaný a má daleko k eleganci?

Kde se dá zjednodušit?

[LSP]

Aby tu nebylo jen pusté filosofování, zde je "protocol-oriented" kód

1) Takhle to jde v OOP také, samozřejmě.
2) Nejsou tam settery, ty právě způsobovaly ten hlavní problém. Konkrétně ve struct Square nejsou settery na side1 a side2. Immutable objekty neberu jako řešení.

[JSH]

Immutable objekty neberu jako řešení.

Tohle je IMO chyba. Schválně se při programování občas zastav a zamysli se kolik objektů upravuješ a kolik jich vytvoříš a pak jenom předáš. U mně ty immutable objekty jednoznačně vedou a to píšu hlavně v C++, které na to nějak extra zatížené není.

Immutable objekty řeší daleko víc věcí než jenom tohle. Zásadně mění třeba způsob jak synchronizovat vlákna.

Mimochodem, ty geometrické tvary jsou matematické objekty. Na matematické objekty sedne immutable jako zadek na hrnec.

[zboj]

Aby tu nebylo jen pusté filosofování, zde je "protocol-oriented" kód

1) Takhle to jde v OOP také, samozřejmě.
2) Nejsou tam settery, ty právě způsobovaly ten hlavní problém. Konkrétně ve struct Square nejsou settery na side1 a side2. Immutable objekty neberu jako řešení.

1) Nejde (kromě C++, to je na jinou debatu).
2) Právě neměnnost objektů je velká výhoda, i když v tomto případě jde spíše o to, jak se používají protokoly.

[gamer]

Mimochodem, ty geometrické tvary jsou matematické objekty. Na matematické objekty sedne immutable jako zadek na hrnec.

Záleží na aplikaci, když to bude geometrický tvar v počítačové hře, tak s immutable moc nepochodíš, tvar a poloha objektů se mění neustále.

[LSP]

Tohle je IMO chyba. Schválně se při programování občas zastav a zamysli se kolik objektů upravuješ a kolik jich vytvoříš a pak jenom předáš. U mně ty immutable objekty jednoznačně vedou a to píšu hlavně v C++, které na to nějak extra zatížené není.

Immutable objekty řeší daleko víc věcí než jenom tohle. Zásadně mění třeba způsob jak synchronizovat vlákna.

Většinu objektů píšu hlavně proto že potřebuji mutable data a udržet data při změnách konzistentní, nepřekvapivě. Kdyby věděl, že čtvercoobdélníky budou immutable, je pravděpodobné že bych objekty vůbec nepoužil. Synchronizaci vláken mám vyřešenou k dokonalosti.

1) Nejde (kromě C++, to je na jinou debatu).
2) Právě neměnnost objektů je velká výhoda, i když v tomto případě jde spíše o to, jak se používají protokoly.

Protokoly nejdou. Napsat čtyři potomky, to vše bez setterů, jde skoro všude.
Výhoda neměnnosti objektů je vykoupena nevýhodou jejich neustálého kopírování a měnění pointerů na novou kopii a to přináší zase jiné problémy.

[Mirek Prýmek]

Většinu objektů píšu hlavně proto že potřebuji mutable data a udržet data při změnách konzistentní, nepřekvapivě. [...] a měnění pointerů na novou kopii a to přináší zase jiné problémy.

Tohle mi přijde jakože s immutable objekty nemáš moc praktických zkušeností - z jazyků, kde se používají hodně. Protože právě immutable data nemůžou být nekonzistentní z principu, tímhle vůbec není potřeba se zabývat, tenhle problém vůbec neexistuje.

Stejně tak pointery - ty se právě v "ne-mutable" jazycích nepoužívají vůbec, protože k tomu není žádný důvod. Prostě kde mají být data, tam jsou data, a program je jako výrobní linka - něco jde dovnitř, něco jde ven.

Používání pointerů na jedna data na x místech programu je právě to peklo, to největší zlo OOP.