OOP v javascriptu (diskuse)

[deda.jabko]

higher-order functions a closures jsou fajny vynalez.... v javascriptu je s nima jenom jedna potiz... vetsina lidi, co neco dela s javascriptem nebo nejakym jeho klonem, je neni schopna vstrebat... cest takovym vyjimkam, jako jste vy

[Honza Jaroš]

Místo

function Pes(stekot) {
   var psiObjekt = {
      zastekej : function () {
         alert(stekot);
      }
   };
   return psiObjekt;
}

jde také napsat

var Pes = function(stekot) {
   this.st = stekot;
}
Pes.prototype.zastekej = function() {
  alert(this.st);
}

Rozdíl je tu v obsazené paměti, v prvním případě má každá instance psa svoji vlastní metodu zastekej, ve druhém případě tuto metodu sdílejí.

[Michal]

V dolní části článku o tomto právě píši. Tohle je způsob OOP v javascriptu, který nemám rád. Je to dáno právě použitím onoho this, na které se nedá vždy spolehnout, protože javascript ho implmentuje chybně. V tomto případě to problém není, ale také se jedná o jednoduchý příklad. V dalším blogpostu ovšem nastíním případ, kdy použití this absolutně selže a chybu aby čert hledal.

[Honza Jaroš]

Budu se těšit (pokud ten blogpost neminu, nesleduju to tu pořád), třeba si zkusím zahrát na čerta

[Honza Jaroš]

PS: zatím jsem si vždy vystačil s "hacky" tohoto typu:

Pes.prototype.lehni() = {
   alert('lehy lehy');
}

Pes.prototype.stekej() = {
   var This = this;
   ...
   var bla = function() {
      This.lehni();
   }
   ...
}

Tak uvidíme, jestli se objeví něco, na co to stačit nebude

[Honza Jaroš]

Ehm, znovu a lépe:

Pes.prototype.lehni = function() {
   alert('lehy lehy');
}

Pes.prototype.stekej = function {
   var This = this;
   ...
   var bla = function() {
      This.lehni();
   }
   ...
}

[Michal]

Ano tyto hacky pomáhají.

[Václav HFechs Švirga]

Na zdrojak.cz byla serie článků o JS od pixyho + zajímavá diskuze. V JS nepíšu, jen mi utkvělo v paměti, že to ztrácení this je normální vlastnost JS a bylo tam vysvětleno proč a kdy se to tak děje. Ale jde to celkem mimo mě.

[dark]

ono ten this si můžete změnit při zavolání kterékoliv funkce:

function ahoj() { alert(this); }

var a = "ahoj";
ahoj.call(a);

Spíš jde o to, že programátoři mnohdy ani neví, jak javascript funguje, a pak pak píšou blbosti:)

[dark]

Toto ale není vůbec potřeba. Pokud máte funkci, která přijímá jako parametr jinou funkci, je potřeba přidat argument pro kontext funkce (právě ten parametr this). Pokud bude stekej součást nějakého event handleru, tak opět je možné přidat spolu s funkcí její kontext, popřípadě to obalit do jen v tom event handleru.

 

[dark]

 

V dolní části článku o tomto právě píši. Tohle je způsob OOP v javascriptu, který nemám rád. Je to dáno právě použitím onoho this, na které se nedá vždy spolehnout, protože javascript ho implmentuje chybně. V tomto případě to problém není, ale také se jedná o jednoduchý příklad. V dalším blogpostu ovšem nastíním případ, kdy použití this absolutně selže a chybu aby čert hledal.

 

To, že některý způsob nemáte rád, ještě neznamená, že není správný. Z hlediska efektivity a čitelnosti kódu je to skoro ten nejlepší způsob vytváření tříd v JS (a je doporučený). Všechno ostatní jsou jen nádstavby nad právě tímto způsobem. Zajímalo by mě ještě, v čem javascript implementuje chybně this? Opět, to že jste nepochopil, jak to celé funguje, ještě nemusí znamenat, že je špatně navržený interpret jazyka. První pravidlo při vývoji totiž je, že pokud mi něco nefunguje, tak je v 98.5% (doplň číslo podle stability knihoven) případech chyba na mé straně.

[Michal]

Dobrá opravím tedy své tvrzení z chybně, na velice nestandartně, či velice matoucím způsobem. Setkávám se s lidmi, řešícími právě tento problém velice často. Proto ho nedoporučuji. Nikde jsem navíc nenapsal, že tento způsob OOP v javascriptu je jediný správný. Ba naopak, na konci článku to zmiňuji.

[dark]

Jen otázka. Když někdo bude špatně programovat v C++, je to chyba jazyka nebo programátora? V javascriptu je to úplně stejně. Pokud má někdo v javascriptu problém s this, první, co bych doporučil, je otevřít knihu, která se zabývá programováním v javascriptu. Po přečtení jedné nebo dvou kapitol to tomu člověku buď doklapne, nebo by měl čtení opakovat:) Nemá cenu psát nesmysly typu var This = this a vnořovat funkce tam, kde nejsou potřeba. Javascript je OO jazyk, kde i funkce je objekt, proto vám to asi připadá matoucí, nestandardní? Jak by jo bylo podle vás nematoucí a standardní?

[Michal]

Ano já sám hacky nemám rád. Ani mě nenapadá jak by to nemělo být matoucí. Ono používání this má hlavně význam pokud se odkazuji na člena, který je můj a je privátní. Tím můj mám namysli, že je v kontextu objektu, se kterým zrovna pracuji. To se ovšem v javascriptu špatně určuje. Mohu mít vlastně 10 objektů zanořených do sebe. Interpret pak může jen věštit z magické koule k jakému objektu chci this přiřadit. Je tedy pravda, že vývojáři javascriptu zvlolili správně přiřazení this k nejbližšímu objektu. Tudíž ano správné to je(uznávám svou chybu), ale stále si stojím na svém v tom, že je lepší se použití this vyhnout, pokud při profilování aplikace nezjistím zásadní výkonostní problém.

[dark]

Ano já sám hacky nemám rád. Ani mě nenapadá jak by to nemělo být matoucí. Ono používání this má hlavně význam pokud se odkazuji na člena, který je můj a je privátní

Nic jako privátní v js neexistuje. To co popisujete vy jsou lokální proměnné.

To se ovšem v javascriptu špatně určuje. Mohu mít vlastně 10 objektů zanořených do sebe. Interpret pak může jen věštit z magické koule k jakému objektu chci this přiřadit. Je tedy pravda, že vývojáři javascriptu zvlolili správně přiřazení this k nejbližšímu objektu.

Javascript nikdy nevěští. Pokud není známý kontext, použije se window (toto je standardní postup). Zanořovat 10 objektů může asi jen blázen V nejhorším případě stačí 2 - funkce dané třídy a inline event handler, popřípadě ještě jeden inline event handler.

ale stále si stojím na svém v tom, že je lepší se použití this vyhnout, pokud při profilování aplikace nezjistím zásadní výkonostní problém.

Ale vyhnout se this znamená nepoužít ten jediný nativní objektový model, který máte k dispozici. Jak chtece psát objektový kód na úrovni bez používání nativních funkcí daného jazyka? Objektový model popsaný v článku je problémový, nepřehledný, paměťově náročný a nevýkonný. Neplyne z něj ani jedna výhoda, a v budoucnu, až vám naroste codebase ho stejně budete přepisovat na nějaký jiný, protože vám to přeroste přes hlavu. Zajímal by mě jeden jediný důvod k použití právě objektového modelu zmíněného v článku. Navíc mám silné pochybnosti o tom, že k pochopení je váš model jednodušší než ten standardní implementovaný pomocí Object.prototype.

[Michal]

Vcelku mě mrzí, že jste mě tak moc v této odpovědi chytal za slovíčka. V dalším článku se rozepíši o motivaci, proč já vlastně nepoužívám this. Intuitivní mi můj přístup příjde v tom, že prostě vytvořím objekt. Netvořím funkci, nad kterou když zavolám new získám objekt. Ovšem prosím, neříkám že je to špatně, jen říkám v čem to mě, přijde intuitivnější.

[dark]

Berte to trochu s nadhledem;)

Rozepište se, mi to zatím bohužel přijde jako nepochopení koncepce JS a zavírání dveří před sebou samotným.

[Michal]

Já to beru s nadhledem, ale občas mi přijde, že lidé zbytečně vypichují slovíčka z kontextu a dávají jim význam, který původně neměli. Pokud se k tomu ještě dnes dostanu napíši co oceňuji na javascriptu a proč se mi tak líbí. Bude tam obsažen právě i důvod proč nepoužívám prototypovou dědičnost.

[dark]

OOP v javascriptu jsem se hodně zabýval, pak jsem objevil toolkit qooxdoo, který tomu dává celkem šťávu. Napsal jsem proto lightweight knihovnu BLite, která implementuje velmi podobný model.

Příklad:

BLite.Object.define("company.BaseClass", {
  // dedicnost
  extend: Blite.Object,

  construct: function() {
    // zavola superclass konstruktor
    this.base(arguments);
  },
  members: {
    sayHello: function() { throw new Error("This method must be reimplemented"); }
  }
});

BLite.Object.define("company.YourClass", {
  // dedicnost
  extend: company.BaseClass,

  construct: function() {
    // zavola superclass konstruktor
    this.base(arguments);
  },
  members: {
    sayHello: function() { alert("Hello"); }
  }
});

var o = new company.YourClass();
alert(o instanceof company.BaseClass); // true
o.sayHello(); // Hello

Výhodou je dědičnost a možnost použít instanceof + další blbosti. Dále pak asi jednoduchost. Ale neviděl jsem nikoho, kdo by měl potřebu používat takovou knihovnu s tak silným OOP pro obyč stránky, většinou se to dělá stylem jquery (který mi teda nesedl).

[dark]

Ještě bych dodal, že ve světě JS se uchytil celkem jednoduchý koncept pro vytváření protected a private members. Protected je s jedním podtržítkem a private se dvěma. Jednoduché a snadno zapamatovatelné. Některé tooly (třeba qooxdoo generator) jsou schopné private metody přejmenovat ve výsledném buildu.

[Michal]

Javascript je jedinečný jazyk, do kterého je vyloženě škoda vměstnávat věci jako je (klasická) dědičnost, protected členy a navíc ještě typovost pro využití instanceof. Javascript tyto věci nemá, protože je nepotřebuje. Není to tím, že by se javascript používál na jednoduché stránky, kde jsou tyto věci k ničemu. Je to tím, že v javascriptu se problémy, které tyto vlastnosti jiných jezyků řeší, řeší jinak. Je tudíž zbytečné hackovat javascript, aby to podporoval stejně jako ostatní jazyky.

[dark]

Problém je to, že to co uvádíte v článku, jsou naprosté základy, které nestačí a jejich použití je mnohdy neefektivní, jako zrovna to vaše. Víte jake paměťové režie mají z closures? Javascript dědičnost má, a pokud ji nebudete používat (nebo používat špatně), tak se jen ochuzujete o jeden prvek tohoto jazyka. Typovost je opět potřeba a některé knihovny nabízí kontrolu typů ve všech funkcích v debug módu již v základu, proč? Protože je jednodušší ladit kód, kde vám daná knihovna přesně řekne, co je špatně. Ještě snad nikdy jsem nenapsal funkci, ve které bych očekával parametry různých typů tříd (OK pro generiku vynechám String a Number, ale to jsou extra výjimky).

V jednom projektu mám codebase v .js asi okolo 15.000 řádků. Kdybych dědičnost bastlil vašim způsobem, tak se v tom zachvilku nevyznám ani já sám

[Michal]

Věřím, že to může být pro lidi matoucí. Vy jste ovšem názorný příklad programátora, který pracuje s implementací OOP v jazycích jako je C++, C#, Java a pro ty je to matoucí dvojnásob. I já pracuji v Jave a věřte dalo mi hodně práce se přeorientovat. V javascriptu jde zcela o jiný přístup. Ano, máte pravdu, to co jsem zde napsal jsou naprosté základy. Chtěl jsem seznámit více lidí, s tím jak se v javascriptu dá psát objektový kód. Opravdoví zájemci začnou studovat dál. Hodlám samozřejmě ještě něco málo napsat. Já si dokonce troufám tvrdit, že javascript je idelání jazyk na to začít se od píky učit správné objektové programování.

 

[dark]

Jen poznámka. Právě pro programátory v C++/Javě/C# je dobré napsat, že v javascriptu se dá dělat úplně stejně (dokonce lze v některých případech vyžadovat i typovou kontrolu, není to na škodu). Mrkněte třeba na frameworky qooxdoo, smartclient, extjs, dojo, atd. Nemusíte se přece přeorientovávat na to, aby jste byl schopný napsat kvalitní OO kód. Psát správně objektově znamená správně myslet a využít vlastností daného jazyka, které zatím nebyly zmíněny Javascript je jazyk, který je postavený na velmy jednoduchých základech, zajímavé je ale to, že jen málokdo těnto základům opravdu porozumí:)

Rád si přečtu další zápisek, ale doufám, že to bude jeden z těch, který ukáže, jak se věci dělají dobře

[Pavel Křivánek]

Tohle je pro tento účel mnohem vhodnější: comtalk.cz/public/Self/self.avi

Objektový model JavaScriptu vychází právě ze Selfu (selflanguage.org/) a byl bohužel poměrně citelně omezen.

 

[seeker]

 No nic moc prispevek.

Doporucuji knihu JAVASCRIPT: THE GOOD PARTS. Na youtube je i prednaska autora knihy. Vysvetluje tam, proc by se mely objekty delat jinak.