Haszprus

Objektum-orientált JavaScript

©   Haszprus   |   fejlesztés javascript

Eddig az objektum-orientált javascript valahogy kimaradt az életemből. Nem nehéz megindokolni igazából, a helyzet az, hogy a weben előforduló feladatok többsége nem igényel oo js-t, és valahogy nincs agyonreklámozva hogy a js az tulajdonképpen egy oo nyelv. Pedig az. Szóval meg is írtam az első saját js objektumomat egy tutorial alapján, marha nehéz volt, mit ne mondjak, le is publikálom ennek örömére.


<script type="text/javascript"> function userobject(parameter) { this.firstproperty = firstproperty; firstproperty(parameter); function firstproperty (parameter) { document.write("<br />Hello " + parameter); } } var myobject = new userobject("world"); myobject.firstproperty("Haszprus"); </script>

Tud egyébként öröklést is, itt egy jó tutorial: Writing Object-Oriented JavaScript.

A dolognak nagy hasznát fogom venni, mert elég kemény js-használat kezdődik a blog alatt, és hát nem sok undorítóbb dolog van, mint az érezhetően osztályért kiáltó functionöket csak úgy beledobálni egy batárnagy fájlba, a kommunikációjukat pedig globális változókkal megvalósítani…

RSS: hozzászólások ehhez a bejegyzéshez 6 hozzászólás

Szólj hozzá Te is!

Öö, az ilyen proto.type meg jQuery dolgokat nézted már?

Illetve, this.firstproperty = firstproperty; ez mit csinál bindeli/csatolja a függvényt az osztálba metódusként? Meg konstruktor az az, ami nincs berakva külön függvényként, csak úgy benne van az osztály definícióban?

Oké, hogy OO nyelv, csak rondaaa

az érezhetően osztályért kiáltó functionöket csak úgy beledobálni egy batárnagy fájlba, a kommunikációjukat pedig globális változókkal megvalósítani…

Nem kell globalis valtozo ilyen esetben sem. Szepen referenciakent at kell adni a szukseges parametereket, es azokkal dolgozik a fuggveny. A visszateresi erteket is lehet referenciakent atadni, igy lehet modositani is eleg hatekonyan, nem kell a stack-en tarolni semmit (raadasul igy nincs stack overflow sem). Joval hatekonyabb kodot lehet igy irni, mint mindenre objektumot letrehozni, kulon objektumra mutato pointer cimforditasokat vegezni, stb.

Mondjuk en leginkabb C-ben programozom (C++-t esetleg szintaktikai edesitoszerkent, pl. a new miatt hasznalom), es elegge idokritikus kodot kell irnom, ugyhogy az effele szepsegek, mint string referencia egy objektumra (var myobject = new userobject(world) nem megengedhetok.

Nincs ez az OO szemlelet tulhype-olva manapsag? Szerintem ugyanez megvalosithato kulon statikus konyvtarak es strukturak hasznalataval, mikozben gyors marad a kod. Ha jol tudom minden objektumra mutato pointer cimenek feloldasa plusz egy muveletet jelent a procinak. Bar a mostani architekturak direkt fenntartanak erre egy kulon regisztert, viszont ha sok valtozot hasznalsz pl. egy ciklusban, akkor konnyen szuk keresztmetszet lehet a regiszterek szama (6-8 darab van asszem), ugyhogy nem mindig jo objektumokkal dolgozni.

késésben vagyok, úgyhogy csak röviden

NeoXon, a globális változóimra szükség van később meghívott metódusokban is, úgy értem dolgok megjegyzésére szolgálnak a weblap olvasásának ideje alatt (csak akkor van rájuk szükség ha a user megint meghív valamit… azaz nem kötődik egyetlen metódushívás-csoportba). ez nem kiváltható referenciákkal.

Pas, prototype van a blog alatt pár hete (nagyon jó).
konstruktor az, igen,
ronda, igen,
csatolja, igen.

NeoXon, egy jó fordító előre foglal helyet az objektumoknak a memóriában, legalábbis azoknak a dolgoknak/objektumoknak/változóknak, amiknek tudja a méretét, és C/C++-ban mindennek lehet tudni, aminek meg nem, az meg úgyis csak egy pointerrel van távolabb, aminek a feloldása egyetlen művelet, de ez akkor is jelen van, ha nem használsz objektumokat.

Gondolom akkor lehet gond a mutatók feloldásával, ha olyan helyen tárolódnak, vagy a kód olyan részén vannak, amit a fordító nem tud előre megjósolni.

NeoXon,
Ha jol tudom minden objektumra mutato pointer cimenek feloldasa plusz egy muveletet jelent a procinak. Bar a mostani architekturak direkt fenntartanak erre egy kulon regisztert, viszont ha sok valtozot hasznalsz pl. egy ciklusban, akkor konnyen szuk keresztmetszet lehet a regiszterek szama (6-8 darab van asszem)
Nem muszáj a regiszterekben tartani, lehet az L1 vagy az L2 cache-ben, onnan még mindig nagyságrendekkel gyorsabb hozzáférni, mint ha a memóriához kéne fordulni. Ettől függetlenül persze nem kell mindenhol az OO-t erőltetni, de van, ahol hasznos - sőt, sok helyen hasznos. Ha másért nem, azért mert fejlesztési időt spórolsz vele, aminek súlyos költségvonzatai vannak (ha te vagy a projektmenedzser. Ha a fejlesztő vagy és időre fizetnek, akkor persze nem te jársz jobban ). Vagy mert alapvetően IO-specifikus környezetben dolgozol (pl a web tipikusan ilyen), amikor úgyse a CPU lesz a szűk keresztmetszet.

Még egy példa arra, hogy sokszor akkor is majdnem OO megoldásnál kötsz ki, ha nem használsz OO nyelvet: C-ben egy volt kollegám fejleszt egy nagyméretű gráfok analíziséhez használható könyvtárat, amibe besegítek. Semmi C++. Az összes függvénynevet és a statikus változókat prefixelni kell egy igraph_ sztringgel, hogy ne legyen névütközés más könyvtárakkal a linkelésnél. Ezen felül gyakorlatilag minden függvényhívás első paramétere az a gráf objektum, amivel dolgozik a függvény. Ez meg már innentől kezdve majdnem OO+névterezés, csak itt éppen az első paraméterben átadott pointert kell feloldanom, nem az implicit this pointert. (Azért írjuk mégis C-ben, mert Python és R programnyelvekbe is beágyazható a library, és oda egyszerűbb C kóddal dolgozni, meg mert így lefordul Minixen is Volt néhány algoritmus, ami úgy került be az igraph-ba, hogy eredetileg másvalaki írta C++-ban, és csak portoltuk C-re. Nem érezni szignifikáns sebességnövekedést a kétfajta változat között, persze lehet, hogy a C változatot lehetne még gyorsítani pár százalékkal, de ezek sokszor tipikusan olyan hekkelések, amik nem érik meg a belefektetett energiát.

Ettől persze még az eredeti kérdésre (Nincs ez az OO szemlelet tulhype-olva manapsag?) a válasz egyértelműen igen. Főleg mióta az OO-szemlélet olyan buzzword lett, amit már minden, programozáshoz nem értő menedzser is ismer

Lehet, hogy hype-olva van, de azért sok esetben hasznos. Én az utóbbi időben kezdek egyre inkább OO szemléletet használni PHP programozásnál és azt kell mondanom, hogy soxor nagyságrendekkel megkönnyíti a fejlesztést. Átláthatóbb a kód, az öröklés pedig nagy jóság.

Ami a JS-t illeti az OO szemlélettel való ismerkedés kezdetén olvasgattam erre-arra és a JS egy külön állatfaj. Ha vki JS-ben ír OO kódot, akkor az első dolog, amivel szembetalálja magát az az, hogy nincsen olyan, hogy osztály. Lehet úgy kódolni JS-ben, hogy osztály alapon gondolkodunk, de egy komolyabb feladatnál már érezni fogja az ember, hogy ez a JS megerőszakolása, ami nem éppen jó irány (bár kétségtelen, hogy van olyan eset, amikor működik, de mégsem az igazi JS logika). A JS OO mivolta elég szubjektív dolog, ahogy az irásokból észrevettem. Vki azt mondja, hogy ez az igazi OO nyelv, vki azt mondja, hogyy csak objektum alapú. A lényeg, hogy más az OO szemlélet, mert itt minden objektum és előbb vagy utóbb meg kell barátkozni a prototípus láncon keresztüli örökléssel (ami nekem még eléggé idegen dolog).
Hozzászólásod:


Nem vagy bejelentkezve, de...

A)
hozzászólhatsz regisztrálatlanul...

B)
ha regisztrálva vagy, bejelentkezhetsz...