Egy régebbi melós projekt során merült fel a dolog, aztán azóta még nem volt nagyon időm írni róla, pedig akkor eléggé rákattantam a témára. Aztán most, hogy újraírtam a deadlime bejegyzés értékelő rendszerét valami korrektebb formába (azok a kis csillagok jobbra a bejegyzés után...), gondoltam ejtek néhány szót az objektum-orientált JavaScript szépségeiről.

A "JavaScriptben programozás szépségei", mint olyan, nem nagyon merült fel bennem soha, ha ezzel a nyelvvel kellett foglalkoznom (bár ebben biztos az is szerepet játszott, hogy még a különböző keretrendszerek elterjedése előtt az embernek if ágak egész erdejét kellett írnia, hogy a műve végül a főbb böngészőkben működjön). Szerencsére ezen sikerült változtatni.

Tovább...

Annak idején, amikor a sorozat hatodik részét megírtam, még azt hittem, hogy vége a sorozatnak. De hatalmas hibát követtem el. Megfeledkeztem a bejárókról. Ezt a hatalmas hiányosságot igyekszem most hirtelen pótolni ennek a bejegyzésnek a keretein belül. Kezdjük is talán a legelején, hogy mi is az a bejáró (iterator)? A Nagy Könyv keveset mondó ám annál hangzatosabb definíciója szerint minden bejáró, ami úgy viselkedik, mint egy bejáró. Viselkedését - és operátorait - tekintve a bejáró viszont a mutatókhoz hasonlatos. Hasonlóan lehet növelni illetve csökkenteni (a ++ és a -- operátorokkal) vagy az éppen aktuális elem értékét megkapni a * operátor segítségével. Ellenben amíg van nullpointer addig "semmire" mutató bejáró nincsen.

A bejárók lényegében egy egységes felületet kívánnak nyújtani a különböző adatszerkezetekhez, hogy egyes algoritmusoknak ne kelljen tudnia, hogy például egy zsák adatszerkezet az most tömbösen vagy láncolt listásan lett-e vajon megvalósítva. Ugyebár miért is kéne tudnia? Bizonyos algoritmusoknál ez mindegy is.

Tovább...

Elérkezett hát az idő, hogy megtárgyaljuk az osztályok származtatását és az ezekből adódó problémákat. Első nekifutásra az az érzés fogott el, hogy túl nagy fába vágom a fejszémet, amikor egy bejegyzésben akarok mesélni ezekről a dolgokról. Túl sok, túl összetett és még egy normális példát sem lehet hozzá írni, ami nem túl bonyolult de nem is rugaszkodik el annyira a valóságtól.

Annak idején én egy közlekedési példával lettem bevezetve a származtatás világába. Tegyük fel, hogy van egy személygépkocsi, egy tehergépkocsi, egy kamion, stb. osztályunk. Mindegyik osztályban van valami közös, például, hogy van kormánya, meg van X darab kereke. Ezek miatt a közös részek miatt érdemes őket egy bázisosztályból származtatni. Tehát legyen egy járművek osztályunk, amiben megvan minden közös tulajdonság, ami a járműveket jellemzi és minden egyediséget a belőle származtatott osztályokban valósítunk meg.

Tovább...

Annak idején ott hagytuk abba, hogy elkészítettünk egy új adatszerkezetet, ami nem más volt mit a láncolt lista. Elkészítettünk hozzá egy használható felhasználói felületet, aztán elkezdhetünk gondolkozni azon, hogy mi van, ha mi nem egyszerű inteket akarunk abban a listában tárolni, hanem valami teljesen mást? Mert hát miért is akarnánk az inteknél leragadni, amikor annyi minden van még.

Ilyen megközelítésben természetesen eléggé használhatatlannak bizonyul a kódunk, mert csak arra az egy típusra működik megfelelően. Még szerencse, hogy itt vannak a sablonok, amikkel ez a probléma relatíve egyszerűen áthidalható.

Tovább...

Abban a szerencsétlen helyzetben hagytuk abba legutóbb, hogy a left_insert() függvény hiányzott és a szegény objektumnak nem volt felhasználói felülete. De talán abban egyet érthetünk, hogy így is elég hosszúra nyúlt az előző bejegyzés, meg nekem se volt túl sok kedvem hajnali nem tudom hány órakor még a maradék részt kifejteni.
Ami késik, gyakran múlik, de most kivételesen nem. Szóval itt az idő, itt a hely, hogy a félbehagyott osztály elnyerje (még messze nem) végleges formáját.

Tovább...

Ahogy ígértem, itt a harmadik rész is. Mint már az előző ajánlóban említettem, egy adatok tárolására alkalmas szerkezetű objektumot fogunk elkészíteni. Hogy a jövőben elkerüljem az ilyen nyakatekert mondatokat, nevezzük csak a dolgot "láncolt listának". Így gondolom már több embernek ismerős lehet a dolog. Ismét hanyagolnám a további bevezető rizsázást, klattyanjunk a tovább gombra.

Tovább...

El is érkeztünk a második részhez, remélem mindenki türelmetlenül várta már, hogy mi következhet még. Mint az az előző részből látható volt, semmi olyat nem valósítottunk meg, amit C-ben ne tudtunk volna megcsinálni, csak sokkal átláthatóbb lett az egész, szerves egységet alkot, nem arról van csak szó, hogy egy struct köré építünk pár kezelő függvényt. Most lehet azt gondolni, hogy az OOP megszállotja vagyok. Előfordulhat, de miért is tagadnék meg valami olyasmit, ami megkönnyíti az életemet, kevesebb és sokkal átláthatóbb kódot eredményez?

A mai terv első körben a Complex objektum szorzásának (operator*) és az összehasonlító operátornak (operator==) megvalósítása és a komplex számunk megjelenítése valamiféleképpen a képernyőn. Az első két dologgal nem lesz túl sok gondunk az előző rész alapján. Csak két új függvénnyel kell bővítenünk az objektumot:

Tovább...

Egy kis fejtörés után arra az elhatározásra jutottam, hogy az elkerülhetetlennek vélt C++ tudás-felfrissítést egy bejegyzés-sorozat keretében ejtem meg, így legalább nem csak nekem lesz hasznom a dologból.
Feltételezem, hogy aki ez iránt a téma iránt érdeklődik, már rendelkezik némi C++-os illetve C-s tapasztalattal, tehát az alapvető szintaxis ismertetésétől eltekintenék. Hogy rögtön a közepébe vágjunk, első körben a struct nevezetű nyelvi szerkezet felé terelném a szót: a dolog már a C nyelvből is ismerős lehet, a különbség ott kezdődik, hogy immár nem csak különböző típusú változókat gyűjthetünk vele egy kupacba, hanem a hozzájuk tartozó függvényeket is. Igazából én az egyetlen értelmét a C-vel kapcsolatos visszafelé-kompatibilitásban látom ennek a dolognak, mivel egy az egyben ugyanarra a dologra használható mint a class azzal a csöppnyi különbséggel, hogy a struct tagfügvényei és változói alapértelmezésben public, míg a class esetében private részében vannak.

Tovább...