Triedne vs. Prototypové OOP

[Odysseus11]

Dobrý deň, niekde som čítal, že prototypové OOP je lepšie ako triedne. Môžete mi vysvetliť aké výhody má prototypové OOP oproti triedam? Programujem v JScripte a na žiadne zásadné výhody som zatiaľ nenarazil, na druhej strane som narazil na nedostatky, všetko je tam na viac riadkov ako v Jave a C++.

[Reklama]

[rooobertek]

"Lepšie" je veľmi relatívne slovo. Keď niekto celý život písal v assembleri a páči sa mu to, určite mu vyhovuje viac ako triedy alebo prototypy. Rovnako ako s prehliadačmi - vo fórach stále čítam "opera je najlepšia, ostatné je iba odpad", "firefox je najlepší, ostatné je iba odpad", "chrome je najlepšie, ostatné je iba odpad"... Windows je najlepší, linux je najlepší, bsd je najlepšie... A kto má pravdu? Podľa mňa najlepšie je to, čo zrovna potrebuješ a čo ti najviac vyhovuje.

Ale k téme http://en.wikipedia.org/wiki/Prototype-based_programming#Comparison_with_class-based_models . Môžem povedať, že bez ohladu na akademické debaty, len čisto na základe skúseností s reálnym použitím tried a prototypov, je to úplne lajtr šuma fuk. Sú iné, ani jeden z týchto spôsobov nie je lepší alebo horší.

[Logik]

Rozdíl hodně závisí na tom, jak je daná dědičnost v jazyku implementovaná. Třeba dědičnost v pythonu oproti C++ je dosti jiná.

Většinou prototypová dědičnost má výhodu oproti třídní v možnosti dynamicky měnit prototyp objektu - což je silná vlastnost, když se používá dobře (a zoufalost, když špatně), výhoda v třídní dědičnosti je silná typovost (což zpravidla vede k delšímu (musí se typy uvádět) ale méně chybovému kódu).
Ale obojí jde nějak dosáhnout i v druhém typu dědičnosti - jen to tak obvykle nebývá. 

[podlesh]

Je to v podstatě stejná debata jako klasický flame staticky vs. dynamicky typované jazyky (no, ono je to celkem logické).

Je důležité si uvědomit, proč se vlastně OOP používá a co tak zásadního přináší: je to polymorfismus, který přináší vyšší úroveň abstrakce ve srovnání s procedurálními jazyky (a existují i jiné koncepty které toho dosáhnou, např. funkce vyšších řádů či makra). Protoypy nebo třídy+dědičnost už jsou jen způsoby implementace polymorfismu.

[Odysseus11]

Většinou prototypová dědičnost má výhodu oproti třídní v možnosti dynamicky měnit prototyp objektu - což je silná vlastnost

Môžeš prosím uviesť konkrétny príklad, v ktorom dynamická zmena prototypu objektu prínáša  nejaké výhody? A aké sú to vlastne výhody? Vďaka.

[Reklama]

[Logik]

Konkrétně možnost modifikovat prototyp se může hodit, když chce člověk za běhu vytvořit novou třídu (např. s předefinovanou metodou). V běžnym jazyku to asi budu řešit tak, že v bázové třídě udělám vlastnost pointer na funkci a ona metoda bude volat ten pointer - jednotlivý instance pak budou předefinovávat ten pointer. V prototypovym jazyku nadefinuju novej prototyp ("poděděnej" z bázovýho) a změnim mu tu metodu a vytvářim objekty....
Nebo k vytváření patchů ke knihovnám, kterej nechci měnit zdrojovej kód (chci případně upgradovat a zachovač fčnost patche), ale potřebuju udělat úpravu. Není to čistý, ale někdy je to nejlepší řešení. Nebo k implementaci toho, co se v ruby nazývá mixings, popř. obecně k různýmu metaprogramování.

Pak je další hromada technik, který využívaj modifikaci prototype chain - např. jednoduchej příklad je "překrytí" prototypové metody vlastní implementací, např. různé callbacky apod. To jde sice i v neprototypových jazycích, ale v prototypovejch je to daleko elegantnější.

[Inkvizitor]

Logiku, dlouho jsem nečetl na Rootu příspěvek, který by mě doopravdy vyděsil. Až teď ten Tvůj. 

[Lado]

Pekna odpoved je na tomto videu - ma to cca 20 minut a je od tvorcu jazyka Self. Velmi zaujimave a poucne - na tom videu vysvetluje preco je to tak, ak oto je, ake to ma moznosti, co s tym planovali a podobne.

video: http://ftp.squeak.org/Media/Self/Self%20the%20video.avi

[Logik]

Logiku, dlouho jsem nečetl na Rootu příspěvek, který by mě doopravdy vyděsil. Až teď ten Tvůj. 

:-) a co z toho je špatně? Vím, že třeba modifikace cizích knihoven je "nestandardní" postup, pro kterej by měl mít člověk opravdu, ale opravdu důvod - ale někdy rozumější cesta není. Nebo Ty máš nějakej návrh, jak lépe modifikovat cizí knihovny? Přijde Ti lepší varianta modifikovat přímo její kód a při příštím upgradu knihovny strávit další hodiny aplikací patche a kontrolou, že vše proběhlo tak, jak má? A nebo radši tu cizí knihovnu nepoužiješ a ztrávíš x hodin psaním jejího duplikátu?

Co máš např. proti implementaci mixings už nevím vůbec :-) A pokud nic, tak jak ho budeš implementovat v jazyce, kterej to neumí nativně? (např. javascript)?

[JS]

Logiku, dlouho jsem nečetl na Rootu příspěvek, který by mě doopravdy vyděsil. Až teď ten Tvůj. 

Od doby, co jsem cetl knizku http://letoverlambda.com/, me tyhle veci uz nedesi. I kdyz prakticka pouzitelnost je IMHO ponekud sporna.

[ondra.novacisko.cz]

ale někdy rozumější cesta není. Nebo Ty máš nějakej návrh, jak lépe modifikovat cizí knihovny? Přijde Ti lepší varianta modifikovat přímo její kód a při příštím upgradu knihovny strávit další hodiny aplikací patche a kontrolou, že vše proběhlo tak, jak má?

Nedělal bych si iluze, že by tohle prototypové programování vyřešilo lépe. Pořád nestandardní úprava nezaručuje bezpečnost v budoucích verzích.

Mimochodem, z tohoto důvodů raději nepoužívám v C++ private. Protože nikdy nevím, kdy budu potřebovat využit dědičnost, abych mohl implementovat novou funkcionalitu do objektu, který s tím původně nepočítal. To už musí být nějaký extra důvod, abych kód takto uzamknul.

[Logik]

Samozřejmě, modifikace prototypu Ti nezaručí, že to bude v další verzi knihovny fungovat tak, jako v předchozí. Ale narozdíl od modifikace zdrojového kódu máš jistotu, že tvůj patch přijde na správné místo a nemusíš pamatovat na to, že ho musíš po každém updatu aplikovat (byť to rozumně napsaný makefile může zajistit, ale to je další práce).

A i pokud se fčnost knihovny změní, tak furt izolovaně napsaná funkce má větší šanci být reusabilní, než patch, popř. se lépe zandavá do nové verze knihovny.

S tím private dosti souhlasím, i když někdy opodstatněním, pokud se píše superbezpečný kód má: zaručuje, že úpravou v potomku nemůžeš rozbít funkčnost předka. Vzhledem k tomu, že ale to vyžaduje dosti velkou analýzu toho, co všechno musí být private a navíc to jak píšeš často brání modifikacím, je zisk v drtivém počtu případů menší, než přidělaná práce.
Pokud bych ale dělal knihocvnu pro houf kodérů neumětelů, tak to může ve výsledku práci ušetřit.

[ondra.novacisko.cz]

Pokud bych ale dělal knihocvnu pro houf kodérů neumětelů, tak to může ve výsledku práci ušetřit.

Pořád je tu šance, že neumětelé budou spíš objekty používat, než aby je dědili, takže protected ve většině případech postačuje

[Sten]

S tím private dosti souhlasím, i když někdy opodstatněním, pokud se píše superbezpečný kód má: zaručuje, že úpravou v potomku nemůžeš rozbít funkčnost předka. Vzhledem k tomu, že ale to vyžaduje dosti velkou analýzu toho, co všechno musí být private a navíc to jak píšeš často brání modifikacím, je zisk v drtivém počtu případů menší, než přidělaná práce.
Pokud bych ale dělal knihocvnu pro houf kodérů neumětelů, tak to může ve výsledku práci ušetřit.

private nezaručuje vůbec nic:

Kód: [Vybrat]

#define private public
IMHO je to jenom pozůstatek nedomyšleného návrhu z počátků OOP. Mě osobně by přišlo vhodnější private ve funkci současného protected a protected jako kombinace současného protected a public const (tj. potomci mají plný přístup, cizí jenom const).

[Logik]

S tim public const nemáš IMHO pravdu. Jeden z cílů, proč je to tak udělané je, aby uživatelé nepoužívali místo veřejných a zaručených metod střeva. Protože střeva se můžou klidně změnit. Používáním "nedokumentovaných" střev si zakládáš na pořádnej problém... a protected proti tomu chrání.... (nicméně někdy, např. pro účely ladění, by se to hodilo, to zas jo).

Stejně tak private má svůj smysl. Pokud máš nějakou vnitřní stavovou proměnou a chceš zajistit, aby Ti ho žádný potomek obejktu nerozbil, tak to použiješ. Něco podobného je i v o dost mladší javě (final).

Co se týče toho, co private zaručuje a nezaučuje máš pravdu, ale z tohodle pohledu v C++ nezaručuje nic vůbec nic.... Vždycky si může uživatel napsat vlastní header file.
Nicméně, ve svym headeru můžeš tudle možnost odchytit a zařvat.