Vlákno názorů k článku
Třídy, dědičnost a OOP v Javascriptu - I

Pokud se vykašlu na privátnost, pak může nastat problém u potomků, které přeci nemusí zajímat, jaké mám privátní vlastnosti a metody, ne?

Samozřejmě, v případě preference kompozice před dědičností (správně) to je většinou OK, ale chtěl jsem ukázat, že privátní viditelnost má smysl nejen co do dokumentace.

OT: Dál bych byl v seriálu rád za nějakou budoucí zmínku o volání parent konstruktoru.

Položil jste velmi dobrou otázku, a já jsem za ni rád. Přesně takovéhle dotazy obohacují článek. Nejprve ale odpovím na OT: Ano, ve druhém i třetím díle si ukážeme správné (i špatné) volání nejen parent konstruktoru, ale i libovolné jiné, třeba přepsané, metody.

Teď k těm privátním. Nerad bych předbíhal, ale potomek nikdy nezavolá privilegovanou metodu kterou, jak jsme si už řekli, používá Crockford k přístupu k privátním proměnným. Nezavolá, protože metoda začne existovat, až v okamžiku vytváření instance, čili, není součástí prototype. Museli bychom vždy povinně volat rodičovský konstruktor, nebo to nějak hacknout (že to lze prasácky nějak obejít, to nechci ani naznačovat ;)

Můžete namítnout: „A co když metoda sama bude privátní?“ To je případ, který záměrně ve výkladu nezmiňuji. Považuji jej totiž za zbytečný, náchylný k chybám, a svádějící k falešnému pocitu nějakého cool zabezpečení kódu. Je to relikt z ostatních jazyků, který dle mého jde proti duchu Javascriptu, a jehož použití je oprávněné pouze v příkladu s jQuery, microoptimalizací, a podobných vzácných případech. Přesto, jednu implementaci vám ukáži. Podívejte se na tento příklad, ale neberte si z něj příklad ;) http://jsfiddle.net/8EtRB/
Máme kvazi-privátní (ve skutečnosti lokální) metodu toString. Jestli je instanční, nebo statická, závisí na tom, jak metodu voláme. Takto definovaná metoda, může i využívat nějaké privátní statické proměnné, případně manipulovat přímo s instancí, pokud ji instanci předáme. Co je na tom příkladu tedy zlého? Za prvé, jedná se o zásadně jiný zápis. Zatímco v jazyce, který privátní členy podporuje klíčovým slovem private stačí použít klíčové slovo, zde musíme využít closure. Kód se bude hůře refaktorovat. Za druhé, tento zápis nejde změnit, což by nám později vadilo (v posledním díle si ukazujeme jak deklarovat s třídy nejen správně, ale i úsporně). Za třetí, a to je hlavní důvod, je to zcela zbytečné. Proč bych měl v jazyce jako je Javascript něco zapouzdřovat?

Já reagoval na „Mírně to naznačíme podtržítkem v názvu, brutálně pomocí closure. Jestli někde má smysl simulovat privátní proměnné pomocí closure, tak jedině u statických objektů, tedy modulů.“.

BTW: Poslední způsob vytváření třídy taky není zrovna chválen, ale věta „Ukážeme si dvě falešné a jednu správnou.“ napovídá, že by to mohl být ten správný. Asi by to chtělo trošku korekci srozumitelnosti. Já vím, asi to bylo myšleno tak, že to není správný způsob, ale vznikají při něm skutečné třídy.

Sakra to jsou zmatky, měl sem seriál od začátku psát na limit délky jednoho článku, a ne čekat, že to půjde nějak dobře rozdělit ;) Ne, ani poslední uvedený způsob není správný. Správnému způsobu bude věnován celý druhý díl :)

To je celkem jasný. Já ze článku pochopil (nečetl jsem úplně důkladně, něco znám), že správný způsob budou asi ta podtržítka. A na to byla ta moje reakce.

Jinak za informace o parent constructor call děkuju předem.

Pokud se nemůžete dočkat, můžete mrknout na můj článek, kde volání konstruktoru parenta používám ;-)

A už sis jej opravil? ,–)) Koleduješ si o brutální review :)

Jinak, abys mne špatně nepochopil, článek je dobře a poctivě napsán. Jen obsahuje několik strašlivých chyb :o)

Já vím ;-) Některé jsem si uvědomil s odstupem času, ještě dřív, než jsi začal rýt ;-)
Review, resp. přepis bez chyb, jsem právě plánoval tady na Zdrojáku, ale teď mám obavu, že mi to nepovolí, aby tu nebylo přejavascriptováno… Tak asi radši napíšu něco o ASP.NET MVC :o) Ať Ti nelezu do zelí :)

No, prave pasaz o dedicnosti je v tvem jinak dobrem clanku slabinou. Tvrzeni, ze dedicnost v JavaScriptu neexistuje je jadrem problemu. Za takoveho predpokladu by byl i tvuj zpusob volani konstruktoru predka dobrym zpusobem, jak si dedicnost doplnit.

Jenze Javascript dedicnost primo podporuje. Tu prototypickou. O ni a o problemech, ktere nam prinasi – prototyp vs. inicializace instance – bude pocitam pristi dil, takze bych uz v tomto tematu dale nepredbihal :)

A nebo můžete používat knihovnu JAK a používat dědění a volání metod předka jak je vám libo :) http://jak.seznam.cz