Objektum perzisztencia és objektum relációs modell

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "Objektum perzisztencia és objektum relációs modell"

Átírás

1 Objektum perzisztencia és objektum relációs modell Konstantinusz Kft 2009

2 Tartalomjegyzék Bevezetés 3 Mi a perzisztencia? 3 Aktív és passzív programok 4 Miért gond az objektum perzisztencia megvalósítása? 5 Perzisztencia formái 9 Megvalósítás formái: interfész-objektum vs betöltés/mentés 12 Hibernálás 13 Perzisztens tárolás 22 Utószó 29

3 Bevezetés Gyakori, és sokszor problémás téma a programozás világában az a terület, ami az objektumorientált modellek perzisztenciájával foglalkozik Gyakori amiatt, hogy szinte alig lehet objektum-orientált rendszereket megvalósítani úgy, hogy ne találkoznánk ezzel az akadállyal, és problémás abból a szempontból, hogy legtöbb programozási nyelv nem, vagy csak közvetett módon nyújt eszközöket a kezelésére Koncepciók, keretrendszerek ahány rendszer, szinte annyi megoldás Ez persze a legfájdalmasabban a kezdő programozót érinti, aki óhatatlanul, és gyanútlanul belefut ebbe a problémába A gond az, hogy az objektum perzisztencia sokkal problémásabb dolog, mint azt a legtöbben gondolják A helyzetet csak rontja, hogy kézzel fogható, egyértelmű megoldás nem nagyon kínálkozik, de többnyire még a probléma természete sem körvonalazódik igazán azok előtt akik először szembesülnek vele Ezért szeretnék ebben a tanulmányban betekintést, és áttekintést nyújtani ebben a témában, beleértve azt területet is, ami az objektumok adatbázisban való tárolásával foglalkozik, vagyis az Objektum Relációs Modell (röviden ORM) Olyan olvasóknak nyújthat új ismereteket, akik már magabiztosan használják az objektumorientált programozást, és jártasak a relációs adatbázisokban is Főként ajánlom ezt a témát a webes programozás iránt érdeklődőknek, mivel ott az objektum perzisztencia problémája elkerülhetetlenül, és sokkal kifejezettebben jelentkezik, mint bárhol máshol Mi a perzisztencia? A szó jelentése megmaradás, megmaradó A mi esetünkben ez az objektumok "megmaradása" Ezzel problémával akkor kell foglalkoznunk, ha az objektumainknak a program futásán túl (vagy legalábbis az objektum modell élettartamán túl) is meg kell maradniuk, majd később újra visszaállíthatónak kell lenniük Ahhoz hogy egy objektum, illetve egy egész objektum modell maradéktalanul visszaállítható legyen, több információt is tudnunk kell róla

4 Az első, az állapota Ez gyakorlatilag az összes attribútumának az aktuális értékét jelenti A második, az identitása, vagyis hogy melyik osztálynak melyik példányáról van szó A harmadik, amit a legtöbben elfelejtenek, vagy összekevernek az objektum állapotával, az objektum kapcsolatai, illetve függőségei Ez a legtöbb nyelvben, implementációs szinten úgy jelenik meg, mint az objektumok közti referenciák Ha egy objektumnak van olyan attribútuma, amely referencia egy másik objektumra, akkor az egy függőség, vagy kapcsolat Ezt mind ki kell tudni menteni és vissza is kell tudni állítani Nyilván kimentés alatt azt értjük, hogy ezeket az adatokat kiírjuk lemezre, vagy bárhol máshol, a programon kívül tároljuk, majd felhasználjuk amikor újra kell építeni az objektumokat De mikor van szükség perzisztencia megvalósítására? Milyen helyzetekben szükséges ez? A helyzet az, hogy több fajtája is van az objektum perzisztenciának, és nagyon fontos, hogy értsük a különbséget ezek között, mivel teljesen más koncepcionális problémákat oldanak meg, és megvalósításukban is vannak komoly különbségek Mielőtt ezt részletesen megvizsgálnánk, nézzünk meg egy lényeges szempontot ami nagy mértékben befolyásolja, hogy milyen típusú perzisztencia problémákkal találkozhatunk Aktív és passzív programok Osszuk a programokat két csoportra Ezekkel már nyilván mindenki találkozott, legfeljebb csak nem gondolt rá ebben a formában Aktív és passzív programok A kettő közül az aktív programok a legtriviálisabbak mindenki számára Ezek azok a programok amik folyamatosan futnak (vagy tudnak futni), és eközben folyamatosan fogadnak bemenetet, produkálnak kimenetet Ide tartozik gyakorlatilag bármilyen asztali (desktop) alkalmazás, amit szoktunk használni, vagyis szövegszerkesztő, médialejátszó, illetve ami a talán a legegyértelműbb példa: játékok Ezekben az esetekben a perzisztencia a munkamenet, vagy az éppen szerkesztett projekt, vagy dokumentum kimentéseként jelentkezik A másik csoport a passzív programok Ezek kevésbé vannak szem előtt, közvetlenül nem is nagyon találkozunk velük az asztali alkalmazások között Különbség az aktívakhoz képest az, hogy ezek programok nem hivatottak határozatlan ideig futni Van egy véges feladatuk, azt elvégzik, esetleg produkálhatnak egy egyszeri kimenetet, aztán véget ér a futásuk A világ, ami teljes mértékben ilyen programokra épül, az a Web Itt ha tetszik ha nem, muszáj lesz számolni a perzisztenciával, már csak abból az okból kifolyólag is, hogy a webes szkriptek passzívak

5 Emiatt webes alkalmazásoknál a munkamenet állapotát (ha van) menteni kell minden lekérés után Az is szinte evidens, hogy a webes alkalmazások adatbázisokban tárolják az adataikat Miért gond az objektum perzisztencia megvalósítása? A példa kedvéért vegyünk egy aktív programot, mondjuk egy autós játékot Itt elég kézenfekvő, hogy miben nyilvánul meg a perzisztencia Egy játékot el kell tudni menteni, aztán később visszatölteni, hogy ugyanonnan folytassuk Ehhez persze mindent menteni kell, tehát hogy hol van az autónk, merre megy, milyen sebességgel, be van-e kapcsolva a rádió, le van-e húzva az ablak, és így tovább minden objektumot amiből a világ áll Ha eljárás-orientáltan gondolkodnánk, akkor írni kellene egy algoritmust, ami végigmegy mindenen amit ki kell menteni, összeszed minden adatot, és valamilyen formában kiírja lemezre Betöltésnél pedig egyszerűen beolvassuk, és minden változóba, adatstruktúrába visszaírjuk az adatokat Viszont az OO világban nem ilyen egyszerű a helyzet Tegyük fel, hogy egy autót akarunk épp kimenteni Nézzünk meg ennek az autónak, mint objektumnak egy lehetséges kódját A nyelv, amit használni fogunk végig a tanulmányban a példák bemutatására, egy C-szerű fiktív nyelv, ezért csak a koncepcionális megoldásokat hivatott bemutatni, nem egy konkrét nyelvi szintaktikát Tehát itt az autónk: class Autó { Vektor hely; float sebesseg; Motor motor; Rádió radio; Klíma klima; Az autónknak van többek közt helye, sebessége, és alkatrészei mint motor, rádió, klíma

6 Eljárás-orientált szemlélet szerint lenne egy mindentudó, mindenható kód ami tudná, hogy pontosan miből épül fel az autó, kiolvasná az autó állapotát, és az autó elemeinek az állapotát Ez viszont ellentmond az OO filozófiának Az OO világban nincs mindenható és mindentudó kód, vagy objektum Helyette minden objektumnak saját magát kellene tudnia kimenteni Ezt nem is probléma megvalósítani, ez csak kis mértékben változtat a helyzeten Adjunk az autónak egy kiment() metódust, ami visszatér az autó állapotával egy adatcsomag formájában, illetve egy betolt() metódust is, ami egy kapott adatcsomagból visszaállít mindent: class Auto{ Adatcsomag kiment(){ Adatcsomag csomag=new Adatcsomag(); return csomag; void betolt(adatcsomag csomag){ Most már az autó nyilván tudja saját magáról, hogy milyen attribútumai vannak, tudja miket és hogyan kell kimenteni Az egyszerű attribútumok (hely, sebesség) kimentése, majd visszaállítása nem is jelent gondot A gond az autó részeit alkotó objektumok lesznek Ugyanis az OO világnak a leglényegesebb jellemzője az absztrakció, és a polimorfizmus Az autónak van például motorja Tegyük fel hogy a "Motor" osztály csak absztrakt osztály, hiszen motorból többféle típus létezik: class Benzinmotor extends Motor{ class Dieselmotor extends Motor{ Ekkor az autó nincs közvetlenül tisztában azzal, hogy a motor valójában milyen motor Neki elég annyi, hogy rendelkezik a motorok szabványos tulajdonságaival

7 Bár végül is, ez nem jelent gondot, ha motor is saját magát menti ki, az autó pedig csak megkéri a motort, hogy mentse ki magát Így nem kell az autónak tudnia, hogy miből áll egy adott típusú motor: class Auto{ Adatcsomag kiment(){ Adatcsomag csomag=new Adatcsomag(); csomaghozzaad(motorkiment()); return csomag; Ez már majdnem jó is, csak még egy dolog hiányzik Ahhoz, hogy a motort is vissza lehessen állítani (példányosítani), tudni kell annak a konkrét osztályát is Tegyük fel, hogy azt is lekérdezzük a motorról, és azt is az adatcsomagba mentjük Viszont ki fogja visszaállításnál a motort újra példányosítani? Az autó? class Auto{ void betolt(adatcsomag csomag){ motor= new????(????); Motoradat motoradat=csomagget("motoradat"); motorbetolt(motoradat); Itt megint egy problémába ütköztünk Honnan tudja az autó, hogy a motort hogyan kell példányosítani, a konstruktorát hogyan kell meghívni, felparaméterezni? Hiszen nem ismerheti a konkrét motor típusokat Nos, ide kell valami olyan segédobjektum, vagy rendszer, ami azért lesz felelős, hogy "legyártsa" a különböző motor típusokat

8 Szóval innentől kezdve már sokszorosan bonyolultabb ez az egész téma, mint amilyennek elsőre tűnt Ha azt gondolnánk, hogy ennyivel megúsztuk, menjünk még egy lépéssel tovább Nézzük meg a következő helyzetet: class Auto { Személy tulajdonos; Az autónak van tulajdonosa A tulajdonos egy személy objektum De a személy nem az autó része, hanem az autó csak hivatkozik rá Ez csak egy kapcsolat Sőt, egy tulajdonosnak több autója is lehet, tehát több autó is hivatkozhat rá Sőt, ez a kapcsolat változhat is idővel Ezt a hivatkozást is ki kell tudni menteni, de ez több szempontból is gondot okoz Ugyanis, ha több hivatkozás is van ugyanarra a tulajdonosra, akkor az objektumok visszaállításánál nem kell minden autóhoz egy új tulajdonost létrehozni, csak vissza kell állítani a hivatkozásokat ugyanarra az egy személyre Ehhez tudnunk kell az objektumokat azonosítani valami olyan módon, ami nem csak az élettartamuk alatt egyedi, hanem azután is megmarad, hogy az objektumokat kimentettük, és visszaállítottuk Ehhez szintén szükség lesz valami rendszerre, ami ezeket az azonosítókat menedzseli, valahogy így: class Szemely{ int id; class Auto { Személy tulajdonos; void betolt(adatcsomag csomag){ int tulajdonos_id=csomagget("tulajdonos_id"); tulajdonos=perzisztenciamenedzserget(tulajdonos_id);

9 Láthatjuk tehát, hogy egy jó objektum perzisztenciához kell egy külön keretrendszer, ami a színfalak mögött az objektumaink azonosítását, példányosítását, mentését, visszaállítását kezeli Viszont annak ellenére, hogy minden perzisztencia keretrendszer ugyanazokat a problémákat kell hogy megoldja, mégis a perzisztenciának többféle formája is létezik, amiknek a koncepciója és a megvalósítása is eltér Ezeket a különbségeket nagyon fontos megérteni mielőtt fejest ugranánk egy ilyen rendszerbe Perzisztencia formái Két nagy terület van, amiben megnyilvánul a perzisztencia A megvalósítás ugyan hasonló, és különbségek nem olyan szembetűnőek, viszont teljesen eltérő filozófiát képviselnek Sajnos mindkettőre az objektum perzisztencia kifejezést használják, viszont hogy megkülönböztessük őket, most adjunk nekik nevet Ezek lesznek a hibernálás, és a perzisztens tárolás Utóbbit, ha adatbázissal valósítjuk meg, akkor hívjuk ORM-nek Elsőnek vegyük a hibernálást, és vegyünk példának egy játékot Egy játékban le kell tudni menteni a játék aktuális állapotát, aztán később visszatölteni Ez azt jelenti, hogy az objektumaink létrejönnek a memóriában, aztán életük végéig ott élnek, és közben változik is az állapotuk, ahogy műveleteket végzünk velük Az egész objektum-modell végig a memóriában él és működik Amikor kimentjük a játékot, akkor abból a célból tesszük, hogy felfüggesszük a működését, hogy később ugyanonnan tovább folytatódhasson a működése Éppen ezért találó elnevezés a hibernálás: "lefagyasztjuk" hogy később "kiolvasztva" tovább használjuk Ennek viszont egy nagyon fontos filozófiai jelentősége van Ugyanis, amikor kimentem az objektumokat, akkor lemezen léteznek, illetve amég a programot le nem állítom, addig a memóriában és a lemezen is egyszerre A kérdés, amit itt fel kell tennünk az az, hogy melyik "az igazi"? Vagyis hol van az igazi, az "élő objektum"? Valószínűleg itt mindannyian egyetértenénk abban, hogy az igazi, az élő objektum az az, ami a memóriában van Ami a lemezen van, az csak egy képe az objektumnak, de nem ott "él"

10 Ha általánosítani szeretnénk, akkor azt mondhatjuk, hogy a hibernálás az az eset, ahol a munkamenet állapotát mentjük ki, ami lényegében többé-kevésbé magának az alkalmazásnak az állapota, amit épp futtatunk Azt is elmondhatjuk, hogy lényegében itt a teljes objektum-modellt egyszerre mentjük ki és állítjuk vissza, vagy ha nem is az egészet, de legalábbis jól elkülönülő részeit Az viszont biztos, hogy nem lenne értelme darabonként módosítgatni a már mentett állapotot, vagy csak darabjait visszatölteni Akárhogy is, a hibernáció az alkalmazás, vagy a munkamenet állapotának a kimentése, visszaállítása Perzisztens tárolás egy egész más probléma, egész más világ Ez a dolog az adatbázisokhoz kötődik Gondoljunk egy olyan alkalmazásra, ami adatbázissal dolgozik Gondoljunk valami adminisztrációs rendszerre, mint például egy banki rendszer Ügyfelek, számlák, tranzakciók, stb Egy adatbázis már önmagában is lényegében perzisztensen tárolja ezeket az adatokat, hiszen ez is a célja Viszont, ha jobban megnézzük, akkor ezek az "adatok" koncepcionális szinten valójában objektumok Ezt szeretném hangsúlyozni, mivel a legtöbb embernek ez nem egyértelmű A legtöbb embert megtéveszti, ha adatbázissal dolgozik, ugyanis egy adatbázis (többnyire relációs adatbázis) csak adatokkal foglalkozik, illetve azok struktúrájával, de semmi más A viselkedésmodell nincs ott Ezért a legtöbben nem objektumokra gondolnak, ha egy ilyen rendszert kell megtervezni A legtöbben óhatatlanul is eljárás-orientáltnak látják ezt a helyzetet, vagyis hogy van az adatbázis, ami az adatmodell, és van a program ami dolgozik vele, az pedig az eljárás modell De ez nem igaz Elég fura lenne, ha ilyen rendszereket mindenképp eljárásorientáltan kellene megírni Ha elvonatkoztatunk az adatbázistól, akkor például az Ügyfél, a Számla egy-egy osztály lenne, amiknek vannak attribútumaik, kapcsolataik, függőségeik, viselkedésük, identitásuk Amikor, például egy számlán egy tranzakciót akarok végrehajtani, akkor egy számla objektumnak a metódusait akarom meghívni Szóval itt is tisztességes objektum modellről van szó, amit perzisztensen tárolunk egy adatbázisban Csakhogy a különbség a hibernációhoz képest az, hogy itt nem lehet az egész objektum modell egyszerre a memóriában, amikor dolgozni akarok vele Fizikailag lehetetlen, hiszen több millió objektumról is lehet szó Sőt, egy ilyen rendszernek több felhasználója is lehet, tehát nem létezhet minden felhasználónak a gépén egy-egy példánya az objektum modellnek, mert az inkonzisztenciához vezetne

11 Szóval, amire itt szükség van az az, hogy egy objektumot csak ideiglenesen "élesztek fel" az adatbázisból, amíg műveleteket végzek rajta, aztán már mentem is vissza Ezután viszont az objektumot el is dobom Tehát itt, a hibernációval ellentétben egyenként manipulálom az adatbázisban lévő objektumokat Az igazi koncepcionális különbség viszont akkor válik tisztává, ha itt is megkérdezzük magunktól, hogy melyik az "igazi" objektum? Az ami az adatbázisban van, vagy ami a memóriában? Hol "él" igazából az objektum? Az adatbázisban vagy a memóriában? A meglepő válasz pedig az, hogy az adatbázisban Itt az adatbázis képviseli az igazi objektum modellt Az adatbázis az "élő" modell, mivel közvetlenül innen kérünk le adatokat, és közvetlenül ide realizálódik minden művelet eredménye Az adatbázis képviseli a rendszer mindenkori, aktuális, konzisztens állapotát Viszont, ha ez mind igaz, akkor mit jelent az, hogy "betöltök" egy objektumot az adatbázisból, műveleteket végzek vele, aztán "visszamentem"? Amikor betöltöttem, akkor ideiglenesen nem az adatbázisban van az objektum? Nos, a helyzet az, hogy ebben a kérdésben nincs egyetértés Vannak, akik ezt úgy fogják fel, hogy betöltöm az adatbázisból az objektumot, dolgozok vele, aztán visszamentem Tehát igen, ideiglenesen az objektum átköltözik a memóriába, aztán visszamentem az adatbázisba Személy szerint én ezt a felfogást hibásnak tartom Ez ugyanis azt jelenti, hogy az objektum ide-oda ugrál az adatbázis és az alkalmazás között Hol itt, hol ott van Márpedig az igazi objektum csak egy helyen lehet Ez így tisztességes, így konzisztens Ezért én inkább úgy gondolom, hogy az az objektum ami a memóriában létrejön, amivel dolgozok az adott programozási nyelvben, valójában csak egy amolyan "interfész", egy felület az igazi objektumhoz, ami továbbra is az adatbázisban van Ebben a felfogásban valójában nem betöltöm az objektumot az adatbázisból, hanem kérek hozzá egy felületet amin keresztül tudom manipulálni, mintha egy távirányítóm lenne hozzá Ezért a memóriában lévő objektumnak igazából nincs is állapota Az állapot végig az adatbázisban van Ez azt is jelentheti, hogy a nyelvi objektumnak nincsenek is attribútumai Lekérdezhetem őket, írhatom őket, de az közvetlenül az adatbázisból jön, és oda is mentődik Tehát mindezt figyelembe véve láthatjuk, hogy tényleg hatalmas különbség van hibernálás és perzisztens tárolás közt Ugyan mind a kettő ugyanazokkal a kihívásokkal kell hogy megküzdjön, és megvalósítás szintjén is szinte ugyanazokat a dolgokat kell tudniuk (objektumok azonosításának a menedzselése, attribútumok, kapcsolatok, identitás, objektumok példányosítása, stb), mégis óriási koncepcionális különbség van köztük, és egész más módon is használjuk a két megoldást

12 A továbbiakban részletesen megnézzük a megvalósításokat mindkét esetben Megvalósítás formái: interfész-objektum vs betöltés/mentés Mint láttuk korábban, mindenre kiterjedő perzisztencia megvalósításához szükség van valamilyen segéd rendszerre, aminek tudnia kell az objektumok azonosítását, példányosítását, visszaállítását intézni Ebből kiindulva minden perzisztenciával kapcsolatos feladat elvégzésére érdemes bevezetni egy keretrendszert Szeretném előre bocsátani, hogy konkrét megvalósítási technikákból több is szóba jöhet, ne várja senki azt, hogy kaphat egy általánosan igaz megoldást, amit minden helyzetben lehet másolbeilleszt módon lehet felhasználni Más környezetben más jellegű megvalósításra lehet szükség Az itt ismertetett megoldás is csak egy a több lehetőség közül Az első dolog, amit érdemes tisztázni, hogy az adott programozási nyelvnek van-e beépített támogatása objektumok, objektum struktúrák automatikus mentésére Ha van, akkor ez általában az úgynevezett szerializáció Ezt jelenti, hogy az objektumokat átalakítja valamilyen egyszerű karakterlánc szerű (szeriális) reprezentációvá, amit aztán kedvünkre felhasználhatunk, majd egy ilyen szeriális formából vissza tudja állítani a valódi objektumokat Ebben az esetben nem kell semmivel se törődnünk (vagy csak kevés dologgal), mindent a nyelv old meg nekünk Az automatizált szerializáció egyszerű, kényelmes megoldás a munkamenet kimentésére, főleg webes alkalmazásoknál, mivel ott nem fut folyamatosan a programunk, viszont a munkamenet (session) állapotának meg kell maradnia A saját magunknak fejlesztett keretrendszert többféle módon képzelhetjük el Egyrészt, valamilyen segéd objektumok formájában, amik végezhetik más objektumok példányosítását, lekérdezését, mentését, betöltését, stb A másik lehetőség, amit gyakran látunk, hogy van valamilyen ősosztály amiből a perzisztens objektumok származnak, és ez az ősosztály implementálja a perzisztencia kezelés bizonyos funkcióit Olyan is szóba jöhet, hogy van valamilyen perzisztencia interfész, amit a perzisztens objektumok implementálnak, és az ilyen objektumokat kezelik a keretrendszer segédobjektumai

13 Hibernálás Először nézzük meg az egyértelműbb esetet, a hibernálást Itt az alkalmazás vagy a munkamenet állapotát mentjük ki, hogy felfüggeszthessük későbbi folytatás céljából Vegyünk most egy olyan megoldást, ahol egy közös ősosztályból származnak a modellünk objektumai Az első legfontosabb dolog, hogy minden perzisztens objektumunknak legyen egy globálisan egyedi azonosítója Ez szükséges lesz, hogy mentés és visszaállítás között is egyértelműen hivatkozhassunk az objektumainkra, illetve azok egymásra Maradjunk az autós példánál: abstract class Perzisztens { int id; class Auto extends Perzisztens{ A kérdés az, hogy ki és mikor állítja be az id-t? Nyilván azonosítót akkor osztunk egy objektumnak amikor létrejön De mit értünk az alatt, hogy létrejön? Ugyanis az objektumot nem csak akkor példányosítjuk, amikor először megszületik, hanem minden egyes alkalommal amikor betöltjük! Ez azt jelenti, hogy lényeges különbség van létrehozás és visszállítás között Éppen ezért az objektum példányosítása, a visszaállítás eszköze lesz Azok a dolgok pedig, amiket az objektumok születésükkor szoktak végezni a konstruktorukban, át kell hogy kerüljenek valahova máshová Emiatt így módosul a kódunk: abstract class Perzisztens { int id; Perzisztens (int id){ thisid=id; class Auto extends Perzisztens{ void inicializal(vektor hely, Motor motor, Rádió radio){ thishely=hely; thismotor=motor; thisradio=radio;

14 Így tehát, egy autó létrehozásakor először csak egy nyers, üres példány jön létre, mindaddig, amíg meg nem hívjuk az inicializálását, ezután jön majd létre ténylegesen Ahhoz pedig, hogy az azonosító (id) beállítódjon, szükségünk lesz valamilyen objektum menedzserre (nevezzük perzisztencia menedzsernek), ami az objektumaink példányosítását végzi Éppen ezért nem mi fogjuk az objektumainkat példányosítani közvetlenül, hanem megadott osztálynév alapján "kérünk" egy példányt a perzisztencia menedzserünktől Ha azt szeretnénk, hogy perzisztencia menedzserünk közvetlenül osztálynév alapján tudjon objektumokat példányosítani, akkor ezt az adott nyelvnek is támogatnia kell Továbbá ki kell kötnünk azt is, hogy a konstruktorok egységesek legyenek, így a példányosítást egy általános kóddal meg lehet oldani (bár vannak rá módszerek arra is hogy a konstruktor is tetszőleges adatokat kaphasson) Ez a megoldás valahogy így nézhet ki: class PerzisztenciaMenedzser{ int kovetkezo_azonosito=0; Perzisztens peldanyok[]; Perzisztens ujpeldany(string osztalynev){ kovetkezo_azonosito++; //az osztálynév alapján példányosítás természetesen nyelvfüggő, ez egy fiktív példa peldany= new osztalynev (kovetkezo_azonosito); //megjegyzünk egy referenciát a példányokra peldanyok[kovetkezo_azonosito]=peldany; return peldany; Ha a perzisztencia menedzser nem tudja egy általános módon példányosítani az objektumokat, vagy eleve nyelvfüggetlen megoldást szeretnénk, akkor neki is más segédobjektumoktól kell kérnie a példányokat Ezeket hívják object factory-nak, vagyis objektum "gyárnak" Az ötlet az, hogy minden példányosítható perzisztens osztályhoz tartozni fog egy factory A factorynak semmi más dolga nincs, mint példányosítani egyet abból az objektumból aminek a gyártásáért felelős Így minden objektum akár tetszőleges konstruktorral is rendelkezhet A perzisztencia menedzsernek valamilyen módon ismernie kell az összes factoryt, és tudnia kell azt is, hogy melyik osztálynak melyik a factoryja

15 abstract class Factory{ abstract string getosztalynev(); abstract Perzisztens ujpeldany(int id); class AutoFactory extends Factory{ string getosztalynev(){ return "Auto"; Perzisztens ujpeldany(int id){ return new Auto(id); class PerzisztenciaMenedzser{ int kovetkezo_azonosito=0; Perzisztens peldanyok[]; Factory factoryk[]; Factory getfactoryosztalyhoz(string osztalynev){ //kikeresi az a factoryt ami a megadott osztályhoz tartozik és visszatér vele Perzisztens ujpeldany(string osztalynev){ kovetkezo_azonosito++; peldany= getfactoryosztalyhoz(osztalynev)ujpeldany(kovetkezo_azonosito); peldanyok[kovetkezo_azonosito]=peldany; return peldany; Egy ehhez hasonló perzisztencia menedzsernek szüksége lesz arra is, hogy tudjon minden perzisztens objektumról, ezért van egy tömbje, amiben megjegyzi őket Ez később lényeges lesz, és azért is kell, hogy végig tudjunk menni rajtuk, amikor ki kell menteni a teljes objektum modell állapotát

16 Tehát egy autó létrehozása valahogy így néz ki: { PerzisztenciaMenedzser perzisztenciamenedzser; Auto auto=perzisztenciamenedzserujpeldany("auto"); autoinicializal(hely,motor,radio); Természetesen az itt leírt megvalósítás csak egy példa Nemcsak helyzetfüggő, de nyelvfüggő is lehet A lényeg amit általánosságban érteni kell, hogy az objektumok létrehozása és példányosítása elválik, és hogy szükség van valamilyen segédobjektumra, vagy segédrendszerre ami a példányosítást végzi, irányítja Létrehozáshoz hasonlóan objektumok törlése is igényel egy kis pluszt Amikor egy objektumot törlünk, vagy törlődik, el kell távolítanunk a perzisztencia menedzser objektumlistájából is A szemétgyűjtögetős nyelvekben eleve nem is tudnánk addig törölni egy objektumot, amég a perzisztencia menedzser is el nem dobja a referenciáját Ezért érdemes bevezetni egy explicit törlés metódust is az ősosztályba abstract class Perzisztens { int id; void torol(){ perzisztenciamenedzserobjektumtorol(thisid); Nézzük most az attribútumok kimentését Attribútumok alatt olyan dolgokat értünk most, amik vagy primitív típusok, vagy olyan objektumok amik csak valami adatstruktúrát valósítanak meg, pl lista, rekord, stb A lényeg, hogy semmiképp nem önálló perzisztens objektumok, mivel ebben az esetben már kapcsolatról beszélünk, az pedig egy másik perzisztencia probléma

17 Itt két választásunk lehet Az attribútumok szerializációját végezheti maga az objektum, vagy esetleg, ha a nyelv is lehetőséget ad rá, akkor a perzisztencia menedzser valamilyen automatikus, általános formában lekérdezheti, enumáralhatja az objektum attribútumait Az utóbbi elég speciális megoldás, ezért inkább nézzük az elsőt, vagyis hogy az objektum csomagolja be valami szeriális adatszerkezetbe az attribútumait, és visszatér velük, betöltésnél pedig egy ilyen adatcsomagból kiolvassa és visszaállítja az attribútumait: abstract class Perzisztens { abstract Adatcsomag attributomokkiment(); abstract void attributumokbetolt(adatcsomag csomag); class Auto extends Perzisztens { Adatcsomag attributumokkiment(){ Adatcsomag csomag=new Adatcsomag; //itt az autó az attribútumat belerakja a csomagba csomaghozzaad(); return csomag; void attributumokbetolt(adatcsomag csomag){ //kiolvassa az attribútumait, és visszaállítja attributum=csomagget();

18 Ezeknek a metódusoknak a meghívása a perzisztencia menedzserünk feladata lesz Az összes objektum kimentésének a folyamata így nézne ki: class PerzisztenciaMenedzser{ Perzisztens peldanyok[]; void osszeskiment(){ Adatcsomag csomag=new Adatcsomag(); for(int n=0;n<peldanyokgetlength();n++ ){ //azonosító mentése csomaghozzaad(peldanyok[n]id); //lekérdezzük az objektum osztályát, és becsomagoljuk csomaghozzaad(peldanyok[n]getclass()); //attribútumok csomaghozzaad(peldanyok[n]attributumokkiment()); void osszesbetolt(adatcsomag csomag){ for(int n=0;n<csomaggetlength();n++ ){ //kiolvassuk az azonosítót és az osztálynevet int id=csomagget(); string osztalynev=csomagget(); //factorytól kérünk egy üres példányt peldany= getfactoryosztalyhoz(osztalynev)ujpeldany(id); peldanyok[id]=peldany; //visszatöltetjük az objektummal az attribútumait peldanyattributumokbetolt(csomagget());

19 A legnehezebb rész a kapcsolatok kezelése Sajnos a mai fő nyelvek a kapcsolatok fogalmát nem ismerik Helyette az objektumok közti kapcsolatok is csak sima referenciákként jelennek meg Ez pedig zavaró, mert nem minden referencia kapcsolat Például: class Vektor{ int x,y,z; Vektor (int x, int y, int z){ thisx=x; thisy=y; thisz=z; class Szakasz{ Vektor a,b; A szakasz két végpontja egy-egy vektor, és ugyan az "a" és "b" attribútumok objektumreferenciák, ez mégsem kapcsolat Egyszerűen a szakasz adatai Ezeket kimentésnél ugyanúgy attribútumként kellene kezelni, mint ahogy az előbb láttuk Egyszerűen kimentem az értékeiket, aztán beolvasom és beállítom A következő helyzet viszont már egész más: class Auto { Személy tulajdonos; A személy egy független, önálló része a világnak, és nem csak az autó egy adata Arról nem is beszélve, hogy egy személy több autónak is lehet a tulajdonosa, tehát többen hivatkozhatnak rá Pontosan ez az a szituáció, ami miatt teljesen újra kell gondolnunk a kapcsolatok kezelését, és ezért is lesz szükség arra, hogy egyedi azonosítóval legyenek ellátva az objektumaink, és ezért szükséges az is, hogy a perzisztencia menedzserünk tudjon minden objektumról

20 A kapcsolatok kimentéséhez a hivatkozás túloldalán lévő objektumnak az azonosítóját kell mentenünk, visszaállításnál pedig a hivatkozott objektumot szintén az azonosító alapján kell majd lekérdezni a perzisztencia menedzsertől Ennek egy lehetséges módja így nézhet ki: class PerzisztenciaMenedzser{ Perzisztens peldanyok[]; Perzisztens getobjektum(int id){ return peldanyok[id]; class Perzisztens { abstract Adatcsomag kapcsolatkiment(); abstract void kapcsolatbetolt(adatcsomag csomag); class Auto extends Perzisztens { Személy tulajdonos; Adatcsomag kapcsolatkiment(){ csomaghozzad("tulajdonos_id",tulajdonosid); return csomag; void kapcsolatbetolt(adatcsomag csomag){ int tulajdonos_id=csomagget("tulajdonos_id"); tulajdonos=perzisztenciamenedzsergetobjektum(tulajdonos_id);

21 Ezzel megoldódik az gondunk is, hogy egyszerre több autó is hivatkozik ugyanarra a tulajdonosra Gondban akkor lehetünk, ha úgy akarjuk visszaállítani a kapcsolatot, hogy még a tulajdonos objektum nincs visszaállítva, hiszen az objektumok visszaállításának sorrendje nem egyértelmű Erre több megoldás is lehetséges Az első, hogy a perzisztencia menedzserünk getobjektum() metódusát úgy írjuk meg, hogy ha olyan objektumot kérnek tőle, ami még nincs visszaállítva, akkor megpróbálja visszaállítani azt is A másik, hogy az objektumok közti kapcsolatok visszaállítását csak azután kezdjük el, miután az összes objektumot visszaállítottuk A harmadik lehetőség, hogy az objektumaink nem valódi referenciát tárolnak egymásra, hanem csak az azonosítókat, és minden alkalommal amikor szükség van a kapcsolat túloldalán lévő objektumra, akkor lekérdezik azt: class Auto extends Perzisztens{ int tulajdonos; Személy gettulajdonos(){ return perzisztenciamenedzsergetobjektum(tulajdonos); Akinek nem tetszik, hogy a kapcsolat csak egy egyszerű int formájában van tárolva, az megvalósíthatja a kapcsolatokat is objektumként, valahogy így: class Kapcsolat { int id; Perzisztens get(){ return perzisztenciamenedzsergetobjektum(id); void set(perzisztens objektum){ id=objektumid; class Auto extends Perzisztens{ Kapcsolat tulajdonos; Ebben az esetben a kapcsolat objektumot úgy is meg lehet valósítani gyorsabb működés érdekében, hogy letárolja a közvetlen referenciát is a kapcsolat túloldalán alló objektumra, miután megtörtént az első sikeres lekérdezés, és később csak azzal tér vissza

22 Természetesen kapcsolatok kezelésénél is több jó megoldás létezhet, főleg a nyelvi lehetőségek miatt, de a lényeg amit meg kell jegyezni, hogy a kapcsolatokat objektum azonosítókkal kell kezelni, és a perzisztencia menedzsertől kell lekérdezni ezek alapján az objektumokat Végül figyelnünk kell arra, hogy ne próbáljunk meg hivatkozást helyreállítani úgy, hogy a túloldalon lévő objektum még nem létezik Perzisztens tárolás Most térjünk át a perzisztenciának a másik fajtájára, ami az adatbázisokhoz kötődik Mint ahogy azt már említettük, itt az a különbség a hibernációhoz képest, hogy nem az egész objektum modell mentjük és állítjuk vissza, hiszen az fizikailag is lehetetlen lenne Annak a filozófiának is gyakorlati jelentősége van, hogy az "igazi" objektum mindvégig az adatbázisban él Eleve a kiindulási helyzet is az, hogy az adatbázisban vannak az objektumok, és csak akkor kérek le egyet, amikor dolgozni szeretnék vele A perzisztencia legtöbb technikai megoldása itt is szükséges Ugyanúgy kell egy közös ős, amiből az objektumok származnak, kell egyedi azonosító nekik, kell perzisztencia menedzser, és factoryk is Itt is elválik a példányosítás és a létrehozás fogalma, és itt talán a legegyértelműbb, hogy miért Amikor létrehozok egy új objektumot, akkor létre kell jönnie az adatbázisban is az őt reprezentáló bejegyzéseknek, viszont amikor egy létező objektumot kérdezek le, akkor tényleg csak a példány jön létre, adatbázisban nem történik semmi Ezért is van az, hogy ebben a helyzetben én szívesebben gondolok úgy a nyelvi objektumra, mint egyfajta interfészre, aminek nincs saját állapota, hanem csak amolyan távirányítóként működik a valódi objektum manipulálására, amit az adatbázis bejegyzés testesít meg Elválik a nyelvi objektum megsemmisítése, és az objektum tényleges megsemmisítése is A nyelvi objektum megsemmisítése csak annyit jelent, hogy nem kívánok vele tovább dolgozni, ezért eldobom Ezen is jól látszik, hogy az interfész-objektum filozófia a helytálló

23 Mivel itt adatbázisban tárolódnak az objektumaink, ezért a reprezentációjuknak is ehhez kell igazodni Relációs adatbázisban az objektumok tárolása viszonylag egyértelmű Minden osztályt egy tábla reprezentál, aminek minden sora egy objektum, a tábla oszlopai pedig az objektum attribútumai Abban meg kell egyeznie minden táblának, hogy az elsődleges kulcsuk az objektum azonosítója kell hogy legyen Használnunk kell egy külön táblát arra is, hogy az összes létező objektum azonosítóját tárolja, így tudunk minden objektumot enumerálni, és itt tudjuk léptetni az azonosítót is amikor új objektumot kell létrehozni Arra is ki kell találni valamilyen szabályt, vagy rendszert, ami meghatározza hogy mely objektumhoz mely tábla tartozik A legegyszerűbb esetben a tábla nevét érdemes az osztály nevével megegyezőre választani, vagy belőle valamilyen módon származtatni, hogy általánosan kezelhető legyen Kellhet külön táblaszerkezet a kapcsolatok reprezentálására is Relációs adatbázisban a különböző számosságú kapcsolat típusok másképp valósulnak meg Egy az egyhez kapcsolatokat elég egy mezőként reprezentálni ami tartalmazza a hivatkozott objektum azonosítóját, abban az osztályban ahonnan a hivatkozás kiindul Egy a többhöz kapcsolatok esetén a hivatkozott fél tárolja egy mezőjében a hivatkozó fél azonosítóját Több a többhöz esetén pedig kell egy külön tábla, ami a hivatkozó és a hivatkozott fél azonosítóját is tárolja Ha kicsit tudatosabban akarjuk a kapcsolatokat kezelni, akkor érdemes az egy az egyhez és az egy a többhöz kapcsolatokat is külön táblákba kiemelni, így könnyebben enumerálhatóvá válnak

24 Az objektumok lekérdezése ebben a fajta perzisztencia menedzserben kicsit más lesz Mivel itt nincsenek az objektumok előzetesen betöltve, ezért az egyes objektumokat akkor példányosítjuk amikor először lekérdezik Utána már megjegyezhetjük a példányt, és azt adhatjuk vissza legközelebb: class PerzisztenciaMenedzser{ Perzisztens peldanyok[]; Perzisztens getobjektum(int id){ //ha még nem létezik, betöltjük if (peldanyok[id]==null){ //betöltjük az adott azonosítójú objektum osztálynevét osztalynev=adatbázisbetolt("fő_objektum_tábla",id,"osztalynev"); peldanyok[id]=getfactoryosztalyhoz(osztalynev)ujpeldany(id); return peldanyok[id]; Az attribútumok kezelése esetében két utat választhatunk Az első, hogy az objektum lekérdezésekor betöltjük az attribútumait is Ezután szabadon manipulálhatom őket, aztán amikor végeztem, visszamentem őket Viszont ha az objektum úgyis adatbázisban létezik, és ott van az igazi állapota, és a nyelvi objektum csak egyfajta interfészként szolgál, akkor igazából attribútumokra a hagyományos értelemben véve nincs is szükség Az attribútumok igazából az adatbázisban vannak, én pedig csak írom és olvasom őket a nyelvi objektumon keresztül Még ha használok is igazi attribútumokat, azok akkor is csak egy ideiglenes tárolóként szolgálnak a beolvasott értékeknek

25 Tehát lássuk a két esetet, először attribútumokkal: abstract class Perzisztens { int id; Array getattributumok(array attributum_nevek){ tablanev=perzsztenciamenedzsergettablanev(this); return Adatbázisbetolt(tablanev,id,attributum_nevek); void setattributumok(array nev_ertek_parok){ tablanev=perzsztenciamenedzsergettablanev(this); Adatbázismodosit(tablanev,id,nev_ertek_parok); abstract void elment(); abstract void betolt(); class Személy extends Perzisztens{ string nev,cim,telefon; void elment(){ Array adatok= new Array(); adatok["nev"]=nev; adatok["cim"]=cim; adatok["telefon"]=telefon; setattributumok(adatok); void betolt(){ Array adatok; adatok=getattributumok(new Array(nev,cim,telefon)); nev=adatok["nev"]; cim=adatok["cim"]; telefon=adatok["telefon"];

26 Az egyetlen szépséghibája ennek a megvalósításnak az, hogy minden egyes osztálynak implementálnia kell az attribútumainak az elmentését, betöltését Ez elég kényelmetlen dolog Persze segíthet, ha a nyelv lehetőséget ad arra, hogy az attribútumokat tudjuk enumerálni, vagy név alapján elérni, és akkor írhatunk rá egy teljesen általános kódot is az ősosztályban, ami betölti és menti a paraméterben megnevezett attribútumokat Ilyen problémánk viszont nincs ha teljesen elkerüljük az attribútumokat: abstract class Perzisztens { int id; Array getattributumok(array attributum_nevek){ tablanev=perzsztenciamenedzsergettablanev(this); return Adatbázisbetolt(tablanev,id,attributum_nevek); void setattributumok(array nev_ertek_parok){ tablanev=perzsztenciamenedzsergettablanev(this); Adatbázismodosit(tablanev,id,nev_ertek_parok); class Személy extends Perzisztens{ Mindezt teljesen legitim módon megtehetjük, mivel a nyelvi objektum igazából csak a viselkedésmodellt testesíti meg, az állapota pedig, ahogy említettük, permanensen az adatbázisban él Esetleg abba lehetne belekötni, hogy így nem lehet tudni hogy milyen attribútumai vannak igazából az objektumnak, de ezt is orvosolhatjuk egy ehhez hasnonló változtatással: abstract class Perzisztens { abstract Array getattributumnevek(); class Személy extends Perzisztens{ Array getattributumnevek(){ return new Array("nev","cim","telefon");

27 Így meg lehet tudni, hogy egy objektumnak milyen attribútumai vannak, vagy akár enumerálni is lehet könnyedén, ami nagyon hasznos Lássuk mi a helyzet a kapcsolatokkal Mivel nem töltjük be a teljes objektum modellt, ezért az eltérés a hibernációhoz képest itt lesz a legerősebb Itt semmiképpen nem implementálhatjuk a kapcsolatokat közvetlen referenciaként, mint ahogy azt egy hagyományos, memóriában működő objektum modellben tennénk Az oka ennek az, hogy ha szeretnék manipulálni egy objektumot, aminek mondjuk csak az attribútumait szeretném átírni, viszont ennek az objektumnak vannak kapcsolatai száz másik objektumra, akkor azokat az objektumokat nem szeretném betölteni Ha betölteném, akkor be kellene tölteni az általuk hivatkozott objektumokat, aztán meg az azok által hivatkozottakat, és így tovább a végtelenségig Tehát itt mindenképp azt a megoldást kell választani, hogy csak azonosítókkal dolgozunk Sőt, még ennél is tovább kell menni, mert még a hivatkozott objektumok azonosítóit sem tölthetem be, mert lehet hogy már az is olyan sok, hogy fizikailag lehetetlen A legjobb megoldás az, ha követjük az alap filozófiánkat, vagy hogy akkor és csak akkor töltök be egy objektumot amikor dolgozni akarok vele Ez esetben még a kapcsolat túloldalán lévő objektumoknak az azonosítóit is csak akkor olvasom be, ha tényleg dolgozni akarok velük

28 class Kapcsolat { int id; string kapcsolat_nev; Kapcsolat(int id, string kapcsolat_nev){ thisid=id; thiskapcsolat_nev=kapcsolat_nev; int get(){ return AdatbáziskapcsolatBetolt(id,kapcsolat_nev); void set(int id){ AdatbáziskapcsolatModosit(thisid,kapcsolat_nev,id); class Auto extends Perzisztens{ Kapcsolat tulajdonos=new Kapcsolat(thisid,"tulajdonos"); string gettulajdonosnev(){ int szemely_id=tulajdonosget(); Szemely szemely=perzisztenciamenedzsergetobjektum(szemely_id); Array adatok=szemelygetattributumok(new Array("nev")); return adatok["nev"]; A Kapcsolat osztály egyszerű egy az egyhez kapcsolatot valósít meg Ehhez szüksége van a hivatkozó objektum azonosítójára, és a kapcsolat "nevére", ami alapján tudja, hogy mely adatbázisban mely mező reprezentálja ezt a kapcsolatot (persze ezt is sok más módon is meg lehet még oldani) Filozófiánkhoz híven, ha a kapcsolatot lekérdezem, csak egy azonosítót kapok, aztán, ha akarom, majd lekérdezem az ahhoz tartozó objektumot is Ez a megoldás persze nem kőbe vésett törvény, de sokszor előfordul hogy lekérdezek hivatkozásokat csak azért, hogy a visszakapott azonosítókat más kapcsolatokba írjam bele, vagy felhasználjam valami más adatbázis lekérdezésekhez Ekkor pedig szintén nem volt szükségem a tényleges objektumra

29 Utószó Remélem ezután érthetőbb, hogy miért is olyan problémás dolog ez a perzisztencia Még így is, kiemelve az általános jellemzőit, sokféle technikai megvalósítása létezik, arról nem is beszélve, hogy mekkora különbségeket jelentenek a nyelvi lehetőségek, korlátok Szinte biztos, hogy minden programozó fog találkozni ezzel a problémával, és ez egy olyan dolog, amibe nem szabad felkészületlenül beleugrani Már az is elég, ha az ember tisztában van azzal, hogy ez a probléma létezik és hogy vannak rá már megírt, jól működő keretrendszerek amit lehet használni Kész rémálom tud lenni a perzisztencia problémája, ha valaki úgy találkozik szembe vele, hogy nem is ismeri fel Főként ajánlom az elmélyülést ebben a témában azoknak, akik adatbázis alapú alkalmazásokat kívánnak fejleszteni (tehát gyakorlatilag minden webprogramozó), mivel a legtöbben képtelenek összeegyeztetni az objektum orientált programozást a hagyományos relációs adatbázisokkal, és ösztönösen eljárás-orientáltan programoznak, ami valljuk be, már nem a 21 század

Függőség injekció Konstantinusz Kft 2010

Függőség injekció Konstantinusz Kft 2010 Függőség injekció Konstantinusz Kft 2010 1 Tartalomjegyzék 1 Tartalomjegyzék 2 2 Bevezetés 3 3 Függőségek formái 4 4 Függőség kezelés problémái 8 5 Megvalósítás 9 2/16 2 Bevezetés Egy objektum modellben

Részletesebben

Programozási alapismeretek 4.

Programozási alapismeretek 4. Programozási alapismeretek 4. Obejktum-Orientált Programozás Kis Balázs Bevezetés I. Az OO programozási szemlélet, egy merőben más szemlélet, az összes előző szemlélettel (strukturális, moduláris, stb.)

Részletesebben

C++ programozási nyelv

C++ programozási nyelv C++ programozási nyelv Gyakorlat - 13. hét Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2004. december A C++ programozási nyelv Soós Sándor 1/10 Tartalomjegyzék Objektumok

Részletesebben

Programozás III KIINDULÁS. Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg.

Programozás III KIINDULÁS. Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg. KIINDULÁS Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg. Programozás III Az egyszerűség kedvéért mindegyiket a nevük alapján regisztráljuk,

Részletesebben

Programozási nyelvek Java

Programozási nyelvek Java statikus programszerkezet Programozási nyelvek Java Kozsik Tamás előadása alapján Készítette: Nagy Krisztián 2. előadás csomag könyvtárak könyvtárak forrásfájlok bájtkódok (.java) (.class) primitív osztály

Részletesebben

Osztályok. 4. gyakorlat

Osztályok. 4. gyakorlat Osztályok 4. gyakorlat Az osztály fogalma Az objektumok formai leírása, melyek azonos tulajdonsággal és operációkkal rendelkeznek. Osztályból objektum készítését példányosításnak nevezzük. Minden objektum

Részletesebben

Smart Pointer koncepciója

Smart Pointer koncepciója Smart Pointer koncepciója ( Egyszerű Smart Pointer implementálása C++ nyelven ) Bevezetés Mik a smart pointer-ek 1? A válasz egyszerű; a smart pointer-ek olyan mutatók amik okosak. Mit is jelent ez pontosan?

Részletesebben

Webes alkalmazások helyes szerkezete PHP-ban

Webes alkalmazások helyes szerkezete PHP-ban Webes alkalmazások helyes szerkezete PHP-ban Konstantinusz Kft. 2010 1. Tartalomjegyzék 1. Tartalomjegyzék... 2 2. Mi az a leíró?... Hiba! A könyvjelző nem létezik. 3. Közvetett paraméter átadások... Hiba!

Részletesebben

Dr. Pál László, Sapientia EMTE, Csíkszereda WEB PROGRAMOZÁS 2.ELŐADÁS. Objektumorientált programozás 2015-2016

Dr. Pál László, Sapientia EMTE, Csíkszereda WEB PROGRAMOZÁS 2.ELŐADÁS. Objektumorientált programozás 2015-2016 Dr. Pál László, Sapientia EMTE, Csíkszereda WEB PROGRAMOZÁS 2.ELŐADÁS 2015-2016 Objektumorientált programozás OOP PHP-ben 2 A PHP az 5.0-as verziójától megvalósítja az OO eszközrendszerét OO eszközök:

Részletesebben

Enterprise JavaBeans. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem. Az Enterprise JavaBeans

Enterprise JavaBeans. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem. Az Enterprise JavaBeans Enterprise JavaBeans Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Az Enterprise JavaBeans Az Enterprise Javabeans Az Enterprise JavaBeans (EJB) server oldali komponens, amely Az üzleti

Részletesebben

és az instanceof operátor

és az instanceof operátor Java VIII. Az interfacei és az instanceof operátor Krizsán Zoltán Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2005. 10. 24. Java VIII.: Interface JAVA8 / 1 Az interfészről általában

Részletesebben

Java VIII. Az interfacei. és az instanceof operátor. Az interfészről általában. Interfészek JAVA-ban. Krizsán Zoltán

Java VIII. Az interfacei. és az instanceof operátor. Az interfészről általában. Interfészek JAVA-ban. Krizsán Zoltán Java VIII. Az interfacei és az instanceof operátor Krizsán Zoltán Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2005. 10. 24. Java VIII.: Interface JAVA8 / 1 Az interfészről általában

Részletesebben

Enterprise JavaBeans 1.4 platform (EJB 2.0)

Enterprise JavaBeans 1.4 platform (EJB 2.0) Enterprise JavaBeans 1.4 platform (EJB 2.0) Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11.13. Az Enterprise JavaBeans Az Enterprise Javabeans Az Enterprise JavaBeans

Részletesebben

OOP. Alapelvek Elek Tibor

OOP. Alapelvek Elek Tibor OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós

Részletesebben

Pelda öröklődésre: import java.io.*; import java.text.*; import java.util.*; import extra.*;

Pelda öröklődésre: import java.io.*; import java.text.*; import java.util.*; import extra.*; Java osztály készítése, adattagok, és metódusok, láthatóság, konstruktor, destruktor. Objektum létrehozása, használata, öröklés. ( Előfeltétel 12. Tétel ) Az osztály egy olyan típus leíró struktúra, amely

Részletesebben

Bevezetés a Python programozási nyelvbe

Bevezetés a Python programozási nyelvbe Bevezetés a Python programozási nyelvbe 7. Gyakorlat osztályok, objektumok (utolsó módosítás 2018. aug. 28.) Szathmáry László Debreceni Egyetem Informatikai Kar 2018-2019, 1. félév OO programozás Pythonban

Részletesebben

Osztálytervezés és implementációs ajánlások

Osztálytervezés és implementációs ajánlások Osztálytervezés és implementációs ajánlások Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 04. 24. Osztálytervezés és implementációs kérdések OTERV / 1 Osztály tervezés Egy nyelv

Részletesebben

Osztálytervezés és implementációs ajánlások

Osztálytervezés és implementációs ajánlások Osztálytervezés és implementációs ajánlások Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 04. 24. Osztálytervezés és implementációs kérdések OTERV / 1 Osztály tervezés Egy nyelv

Részletesebben

C++ programozási nyelv

C++ programozási nyelv C++ programozási nyelv Gyakorlat - 8. hét Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2004. november A C++ programozási nyelv Soós Sándor 1/12 Tartalomjegyzék Miért

Részletesebben

Programozási nyelvek Java

Programozási nyelvek Java Programozási nyelvek Java Kozsik Tamás előadása alapján Készítette: Nagy Krisztián 9. előadás Interface - típust vezet be, de osztálypéldány nem készíthető belőle (statikus típust ad) - több osztály is

Részletesebben

Java programozási nyelv 4. rész Osztályok II.

Java programozási nyelv 4. rész Osztályok II. Java programozási nyelv 4. rész Osztályok II. Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2005. szeptember A Java programozási nyelv Soós Sándor 1/17 Tartalomjegyzék

Részletesebben

Interfészek. PPT 2007/2008 tavasz.

Interfészek. PPT 2007/2008 tavasz. Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése 2 Már megismert fogalmak áttekintése Objektumorientált

Részletesebben

7. fejezet: Mutatók és tömbök

7. fejezet: Mutatók és tömbök 7. fejezet: Mutatók és tömbök Minden komolyabb programozási nyelvben vannak tömbök, amelyek gondos kezekben komoly fegyvert jelenthetnek. Először is tanuljunk meg tömböt deklarálni! //Tömbök használata

Részletesebben

Miután létrehoztuk, szeretnénk neki beszédesebb nevet adni. A név változtatásához a következőt kell tenni:

Miután létrehoztuk, szeretnénk neki beszédesebb nevet adni. A név változtatásához a következőt kell tenni: Excel objektumok Az excelben az osztályokat úgynevezett class modulokként hozzuk létre. Miután létrehoztuk, szeretnénk neki beszédesebb nevet adni. A név változtatásához a következőt kell tenni: View-ba

Részletesebben

Számítástechnika II. BMEKOKAA Előadás. Dr. Bécsi Tamás

Számítástechnika II. BMEKOKAA Előadás. Dr. Bécsi Tamás Számítástechnika II. BMEKOKAA153 5. Előadás Dr. Bécsi Tamás Kivételkezelés try Azon utasítások kerülnek ide, melyek hibát okozhatnak, kivételkezelést igényelnek catch( típus [név]) Adott kivételtípus esetén

Részletesebben

Objektum orientáltság alapjai A Java nyelv Fordítás - futtatás

Objektum orientáltság alapjai A Java nyelv Fordítás - futtatás Objektum orientáltság alapjai A Java nyelv Fordítás - futtatás Objektum orientáltság alapjai Objektum: A való világ egy elemének ábrázolása, amely minden esetben rendelkezik: Állapottal,Viselkedéssel,Identitással

Részletesebben

Programozás II. 2. gyakorlat Áttérés C-ről C++-ra

Programozás II. 2. gyakorlat Áttérés C-ről C++-ra Programozás II. 2. gyakorlat Áttérés C-ről C++-ra Tartalom Új kommentelési lehetőség Változók deklarációjának helye Alapértelmezett függvényparaméterek Névterek I/O műveletek egyszerűsödése Logikai adattípus,

Részletesebben

Java és web programozás

Java és web programozás Budapesti Műszaki Egyetem 2015. 02. 11. 2. Előadás Mese Néhány programozási módszer: Idők kezdetén való programozás Struktúrált Moduláris Funkcionális Objektum-orientált... Mese Néhány programozási módszer:

Részletesebben

Már megismert fogalmak áttekintése

Már megismert fogalmak áttekintése Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak

Részletesebben

A gyakorlat során MySQL adatbázis szerver és a böngészőben futó phpmyadmin használata javasolt. A gyakorlat során a következőket fogjuk gyakorolni:

A gyakorlat során MySQL adatbázis szerver és a böngészőben futó phpmyadmin használata javasolt. A gyakorlat során a következőket fogjuk gyakorolni: 1 Adatbázis kezelés 3. gyakorlat A gyakorlat során MySQL adatbázis szerver és a böngészőben futó phpmyadmin használata javasolt. A gyakorlat során a következőket fogjuk gyakorolni: Tábla kapcsolatok létrehozása,

Részletesebben

Programozás II gyakorlat. 6. Polimorfizmus

Programozás II gyakorlat. 6. Polimorfizmus Programozás II gyakorlat 6. Polimorfizmus Típuskonverziók C-ben: void * ptr; int * ptr_i = (int*)ptr; Ez működik C++-ban is. Használjuk inkább ezt: int * ptr_i = static_cast(ptr); Csak egymással

Részletesebben

Abstract osztályok és interface-ek. 7-dik gyakorlat

Abstract osztályok és interface-ek. 7-dik gyakorlat Abstract osztályok és interface-ek 7-dik gyakorlat Abstract metódusok és osztályok Az OO fejlesztés során olyan osztályokat is kialakíthatunk, melyeket csak továbbfejlesztésre, származtatásra lehet használni,

Részletesebben

PHP5 Új generáció (2. rész)

PHP5 Új generáció (2. rész) PHP5 Új generáció (2. rész)...avagy hogyan használjuk okosan az osztályokat és objektumokat PHP 5-ben. Cikksorozatom elõzõ részében képet kaphattunk arról, hogy valójában mik is azok az objektumok, milyen

Részletesebben

C++ programozási nyelv Konstruktorok-destruktorok

C++ programozási nyelv Konstruktorok-destruktorok C++ programozási nyelv Konstruktorok-destruktorok Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2004. szeptember A C++ programozási nyelv Soós Sándor 1/20 Tartalomjegyzék

Részletesebben

Objektum orientált kiterjesztés A+ programozási nyelvhez

Objektum orientált kiterjesztés A+ programozási nyelvhez Szegedi Tudományegyetem Informatikai Tanszékcsoport Objektum orientált kiterjesztés A+ programozási nyelvhez Diplomamunka terve Készítette: Bátori Csaba programtervező matematikus hallgató Témavezető:

Részletesebben

Objektumleírók Konstantinusz Kft 2010

Objektumleírók Konstantinusz Kft 2010 Objektumleírók Konstantinusz Kft. 2010 1. Tartalomjegyzék 1. Tartalomjegyzék... 2 2. Mi az a leíró?... 2 3. Közvetett paraméter átadások... 4 4. Absztrakt metódusok, absztrakt konstrukció... 7 5. Validálás

Részletesebben

Programozási technológia

Programozási technológia Programozási technológia Generikus osztályok Gyűjtemények Dr. Szendrei Rudolf ELTE Informatikai Kar 2018. Generikus osztályok Javaban az UML paraméteres osztályainak a generikus (sablon) osztályok felelnek

Részletesebben

ISA szimulátor objektum-orientált modell (C++)

ISA szimulátor objektum-orientált modell (C++) Budapesti Műszaki és Gazdaságtudományi Egyetem ISA szimulátor objektum-orientált modell (C++) Horváth Péter Elektronikus Eszközök Tanszéke 2015. február 12. Horváth Péter ISA szimulátor objektum-orientált

Részletesebben

OOP #14 (referencia-elv)

OOP #14 (referencia-elv) OOP #14 (referencia-elv) v1.0 2003.03.19. 21:22:00 Eszterházy Károly Főiskola Információtechnológia tsz. Hernyák Zoltán adj. e-mail: aroan@ektf.hu web: http://aries.ektf.hu/~aroan OOP OOP_14-1 - E jegyzet

Részletesebben

Adatszerkezetek 2. Dr. Iványi Péter

Adatszerkezetek 2. Dr. Iványi Péter Adatszerkezetek 2. Dr. Iványi Péter 1 Hash tábla A bináris fáknál O(log n) a legjobb eset a keresésre. Ha valamilyen közvetlen címzést használunk, akkor akár O(1) is elérhető. A hash tábla a tömb általánosításaként

Részletesebben

Objektumorientált programozás C# nyelven

Objektumorientált programozás C# nyelven Objektumorientált programozás C# nyelven 2. rész Öröklés és többalakúság Nemvirtuális metódusok, elrejtés Virtuális metódusok, elrejtés Típuskényszerítés, az is és as operátorok Absztrakt osztályok, absztrakt

Részletesebben

Java és web programozás

Java és web programozás Budapesti Műszaki Egyetem 2015. 04. 08. 10. Előadás Ami kimearad múlthéten Ha már megvan a KeyListener vagy MouseListener osztályunk a következõ módon tudjuk hozzárendelni egy JFrame vagy JPanel-hez: Ami

Részletesebben

Az élet szép, környezetünk tele van fákkal, virágokkal, repdeső madarakkal, vidáman futkározó állatokkal.

Az élet szép, környezetünk tele van fákkal, virágokkal, repdeső madarakkal, vidáman futkározó állatokkal. Objektumorientált programozás Az élet szép, környezetünk tele van fákkal, virágokkal, repdeső madarakkal, vidáman futkározó állatokkal. Ez a nem művészi értékű, de idillikus kép azt a pillanatot mutatja,

Részletesebben

Széchenyi István Egyetem. Programozás III. Varjasi Norbert varjasin@sze.hu

Széchenyi István Egyetem. Programozás III. Varjasi Norbert varjasin@sze.hu Programozás III. Varjasi Norbert varjasin@sze.hu 1 A java virtuális gép (JVM) Képzeletbei, ideális számítógép. Szoftveresen megvalósított működési környezet. (az op. rendszer egy folyamata). Feladata:

Részletesebben

Generikus osztályok, gyűjtemények és algoritmusok

Generikus osztályok, gyűjtemények és algoritmusok Programozási, gyűjtemények és algoritmusok bejárása Informatikai Kar Eötvös Loránd Tudományegyetem 1 Tartalom 1 bejárása 2 bejárása 2 Java-ban és UML-ben bejárása Az UML-beli paraméteres osztályok a Java

Részletesebben

JAVA PROGRAMOZÁS 2.ELŐADÁS

JAVA PROGRAMOZÁS 2.ELŐADÁS Dr. Pál László, Sapientia EMTE, Csíkszereda JAVA PROGRAMOZÁS 2.ELŐADÁS 2014-2015 tavasz Tömbök, osztályok, objektumok, konstruktorok Tömbök 2 Referencia típusú változó Elemtípus Primitív Referencia: osztály,

Részletesebben

Bevezetés a Python programozási nyelvbe

Bevezetés a Python programozási nyelvbe Bevezetés a Python programozási nyelvbe 8. Gyakorlat modulok random számok (utolsó módosítás: 2017. aug. 3.) Szathmáry László Debreceni Egyetem Informatikai Kar 2017-2018, 1. félév Modulok Amint a programunk

Részletesebben

Java programozási nyelv 5. rész Osztályok III.

Java programozási nyelv 5. rész Osztályok III. Java programozási nyelv 5. rész Osztályok III. Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2005. szeptember A Java programozási nyelv Soós Sándor 1/20 Tartalomjegyzék

Részletesebben

Adatstruktúrák, algoritmusok, objektumok

Adatstruktúrák, algoritmusok, objektumok Adatstruktúrák, algoritmusok, objektumok 3. Az objektumorientált paradigma alapelemei Objektum Osztály Példányosítás A konstruktor és a destruktor Osztályok közötti kapcsolatok Miklós Árpád, BMF NIK, 2006

Részletesebben

Objektum Orientált Programozás. 11. Kivételkezelés 44/1B IT MAN

Objektum Orientált Programozás. 11. Kivételkezelés 44/1B IT MAN Objektum Orientált Programozás 11. Kivételkezelés 44/1B IT MAN B IT v: 2016.05.03 MAN Pici elmélet A Java kivételkezelésének célja a programfutás során keletkezett hibák kiszűrése és megfelelő kezelése.

Részletesebben

OOP: Java 8.Gy: Abstract osztályok, interfészek

OOP: Java 8.Gy: Abstract osztályok, interfészek OOP: Java 8.Gy: Abstract osztályok, interfészek 26/1 B ITv: MAN 2019.04.03 Abszrakt metódus és absztrakt osztály. Gyakran előfordul a tervezés során, hogy egy osztály szintjén tudjuk, hogy valamilyen metódus

Részletesebben

Programozás C++ -ban

Programozás C++ -ban 8. Dinamikus objektumok Programozás C++ -ban Ahhoz hogy általános prolémákat is meg tudjunk oldani, szükség van arra, hogy dinamikusan hozhassunk létre vagy szüntethessünk meg objektumokat. A C programozási

Részletesebben

OOP #1 (Bevezetés) v1.0 2003.03.07. 18:39:00. Eszterházy Károly Főiskola Információtechnológia tsz. Hernyák Zoltán adj.

OOP #1 (Bevezetés) v1.0 2003.03.07. 18:39:00. Eszterházy Károly Főiskola Információtechnológia tsz. Hernyák Zoltán adj. OOP #1 (Bevezetés) v1.0 2003.03.07. 18:39:00 Eszterházy Károly Főiskola Információtechnológia tsz. Hernyák Zoltán adj. e-mail: aroan@ektf.hu web: http://aries.ektf.hu/~aroan OOP OOP_01-1 - E jegyzet másolata

Részletesebben

Objektumorientált paradigma és programfejlesztés Bevezető

Objektumorientált paradigma és programfejlesztés Bevezető Objektumorientált paradigma és programfejlesztés Bevezető Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján

Részletesebben

Se S r e ial a iza z t a ion o n (in n Ja J v a a v ) a Szerializáció

Se S r e ial a iza z t a ion o n (in n Ja J v a a v ) a Szerializáció Serialization (in Java) Szerializáció Java Serialization API Standard eljárás az objektumok állapotának adatfolyamba történő kiírására (elmentésére egy bájtszekvenciába), és visszatöltésére Perzisztencia

Részletesebben

Programozás II. 4. Dr. Iványi Péter

Programozás II. 4. Dr. Iványi Péter Programozás II. 4. Dr. Iványi Péter 1 inline függvények Bizonyos függvények annyira rövidek, hogy nem biztos hogy a fordító függvényhívást fordít, hanem inkább az adott sorba beilleszti a kódot. #include

Részletesebben

Java VI. Egy kis kitérő: az UML. Osztály diagram. Általános Informatikai Tanszék Utolsó módosítás: 2006. 03. 07.

Java VI. Egy kis kitérő: az UML. Osztály diagram. Általános Informatikai Tanszék Utolsó módosítás: 2006. 03. 07. Java VI. Öröklődés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 03. 07. Java VI.: Öröklődés JAVA6 / 1 Egy kis kitérő: az UML UML: Unified Modelling Language Grafikus eszköz objektum

Részletesebben

ADATMENTÉSSEL KAPCSOLATOS 7 LEGNAGYOBB HIBA

ADATMENTÉSSEL KAPCSOLATOS 7 LEGNAGYOBB HIBA ADATMENTÉSSEL KAPCSOLATOS 7 LEGNAGYOBB HIBA Készítette: Hunet Kft, 2013 Ez az alkotás a Creative Commons Nevezd meg! - Ne add el! - Így add tovább! 2.5 Magyarország licenc alá tartozik. A licenc megtekintéséhez

Részletesebben

Web-programozó Web-programozó

Web-programozó Web-programozó Az Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő felvétel és törlés eljárási rendjéről szóló 133/2010. (IV. 22.) Korm. rendelet alapján. Szakképesítés, szakképesítés-elágazás, rész-szakképesítés,

Részletesebben

Adatbázis, adatbázis-kezelő

Adatbázis, adatbázis-kezelő Adatbázisok I. rész Adatbázis, adatbázis-kezelő Adatbázis: Nagy adathalmaz Közvetlenül elérhető háttértárolón (pl. merevlemez) Jól szervezett Osztott Adatbázis-kezelő szoftver hozzáadás, lekérdezés, módosítás,

Részletesebben

A gyakorlat során MySQL adatbázis szerver és a böngészőben futó phpmyadmin használata javasolt. A gyakorlat során a következőket fogjuk gyakorolni:

A gyakorlat során MySQL adatbázis szerver és a böngészőben futó phpmyadmin használata javasolt. A gyakorlat során a következőket fogjuk gyakorolni: 1 Adatbázis kezelés 2. gyakorlat A gyakorlat során MySQL adatbázis szerver és a böngészőben futó phpmyadmin használata javasolt. A gyakorlat során a következőket fogjuk gyakorolni: Táblák létrehozása,

Részletesebben

OOP: Java 11.Gy: Enumok, beágyazott osztályok. 13/1 B ITv: MAN

OOP: Java 11.Gy: Enumok, beágyazott osztályok. 13/1 B ITv: MAN OOP: Java 11.Gy: Enumok, beágyazott osztályok 13/1 B ITv: MAN 2019.04.24 ArrayList Rugalmas tömb A tömbök korlátai Fix méret, nem lehet menet közben megnövelni Ha túl nagyra választjuk, fölösleges helyfoglalás

Részletesebben

Java V. Osztályszint. lyszintű ű tagok. Példányváltozó. Osztályváltozó. Általános Informatikai Tanszék Utolsó módosítás:

Java V. Osztályszint. lyszintű ű tagok. Példányváltozó. Osztályváltozó. Általános Informatikai Tanszék Utolsó módosítás: Java V. szint lyszintű ű tagok A final minősítő Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2005. 10. 05. Java V.: szintű tagok JAVA5 / 1 Példányváltozó Az eddig megismert adattagokból

Részletesebben

Adatbázismodellek. 1. ábra Hierarchikus modell

Adatbázismodellek. 1. ábra Hierarchikus modell Eddig az adatbázisokkal általános szempontból foglalkoztunk: mire valók, milyen elemekből épülnek fel. Ennek során tisztáztuk, hogy létezik az adatbázis fogalmi modellje (adatbázisterv), amely az egyedek,

Részletesebben

Adatszerkezetek Tömb, sor, verem. Dr. Iványi Péter

Adatszerkezetek Tömb, sor, verem. Dr. Iványi Péter Adatszerkezetek Tömb, sor, verem Dr. Iványi Péter 1 Adat Adat minden, amit a számítógépünkben tárolunk és a külvilágból jön Az adatnak két fontos tulajdonsága van: Értéke Típusa 2 Adat típusa Az adatot

Részletesebben

Java. Perzisztencia. ANTAL Margit. Java Persistence API. Object Relational Mapping. Perzisztencia. Entity components. ANTAL Margit.

Java. Perzisztencia. ANTAL Margit. Java Persistence API. Object Relational Mapping. Perzisztencia. Entity components. ANTAL Margit. Sapientia - EMTE 2008 Az előadás célja JPA - - perzisztencia ORM - - Objektumrelációs leképzés - Entitásbabok Állandóság Mechanizmus amely során az alkalmazás adatai megőrzésre kerülnek valamely perzisztens

Részletesebben

Miért tanulod a nyelvtant?

Miért tanulod a nyelvtant? Szilágyi N. Sándor Mi kell a beszédhez? Miért tanulod a nyelvtant? Nyelvtani kiskalauz (Részletek a szerző Ne lógasd a nyelved hiába! c. kötetéből, Anyanyelvápolók Erdélyi Szövetsége, 2000) 2. rész Térjünk

Részletesebben

Webprogramozás szakkör

Webprogramozás szakkör Webprogramozás szakkör Előadás 5 (2012.04.09) Programozás alapok Eddig amit láttunk: Programozás lépései o Feladat leírása (specifikáció) o Algoritmizálás, tervezés (folyamatábra, pszeudokód) o Programozás

Részletesebben

3. Osztályok II. Programozás II

3. Osztályok II. Programozás II 3. Osztályok II. Programozás II Bevezető feladat Írj egy Nevsor osztályt, amely legfeljebb adott mennyiségű nevet képes eltárolni. A maximálisan tárolható nevek számát a konstruktorban adjuk meg. Az osztályt

Részletesebben

Objektumelvű programozás

Objektumelvű programozás Objektum, osztály Objektumelvű programozás Az elemzés együttműködő objektumok rendszereként fogalmazza meg a feladatot. Objektum-központú elemzés A tervezés a feladat tárgyköreit egy-egy objektum felelősségévé

Részletesebben

Objektumorientált paradigma és a programfejlesztés

Objektumorientált paradigma és a programfejlesztés Objektumorientált paradigma és a programfejlesztés Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján Objektumorientált

Részletesebben

Programozás II. 3. gyakorlat Objektum Orientáltság C++-ban

Programozás II. 3. gyakorlat Objektum Orientáltság C++-ban Programozás II. 3. gyakorlat Objektum Orientáltság C++-ban Tartalom OOP ismétlés Osztályok létrehozása Adattagok láthatóságai, elnevezési ajánlások Konstruktor, destruktor this pointer Statikus és dinamikus

Részletesebben

Temporális adatbázisok. Kunok Balázs szakdolgozata alapján

Temporális adatbázisok. Kunok Balázs szakdolgozata alapján Temporális adatbázisok Kunok Balázs szakdolgozata alapján Miért? Döntéshozatalok körülményeinek meghatározása. Nem csak az a lényeges, hogy hogyan változott az adat, hanem az is, hogy miért. Adatok helyreállíthatók

Részletesebben

Concurrency in Swing

Concurrency in Swing Concurrency in Swing A szálkezelés a swing alkalmazásokban is fontos. Cél egy olyan felhasználói felület készítése, amely soha nem fagy, mindig válaszol a felhasználói interakciókra, bármit is csináljon

Részletesebben

Bevezetés a programozásba Előadás: Tagfüggvények, osztály, objektum

Bevezetés a programozásba Előadás: Tagfüggvények, osztály, objektum Bevezetés a programozásba 2 1. Előadás: Tagfüggvények, osztály, objektum Ismétlés int main() { string s; s; s= bla ; cout

Részletesebben

Statikus adattagok. Statikus adattag inicializálása. Speciális adattagok és tagfüggvények. Általános Informatikai Tanszék

Statikus adattagok. Statikus adattag inicializálása. Speciális adattagok és tagfüggvények. Általános Informatikai Tanszék Speciális adattagok és tagfüek Miskolci Egyetem Általános Informatikai Tanszék CPP7 / 1 Statikus adattagok Bármely adattag lehet static tárolási osztályú A statikus adattag az osztály valamennyi objektuma

Részletesebben

Programozás C++ -ban 2007/7

Programozás C++ -ban 2007/7 Programozás C++ -ban 2007/7 1. Másoló konstruktor Az egyik legnehezebben érthető fogalom C++ -ban a másoló konstruktor, vagy angolul "copy-constructor". Ez a konstruktor fontos szerepet játszik az argumentum

Részletesebben

Adatbázis rendszerek 6.. 6. 1.1. Definíciók:

Adatbázis rendszerek 6.. 6. 1.1. Definíciók: Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika 6.1. Egyed relációs modell lényegi jellemzői 6.2. Egyed relációs ábrázolás 6.3. Az egyedtípus 6.4. A

Részletesebben

Erdő generálása a BVEPreproc programmal

Erdő generálása a BVEPreproc programmal Erdő generálása a BVEPreproc programmal Első lépés, hogy elkészítjük a falevél objektumot. Ezeket fogjuk rárakni a faág objektumokra, majd jön a fatörzs... Ez csak vicc volt. Elkészítjük/összeollózzuk

Részletesebben

GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és. Függvénysablonok

GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és. Függvénysablonok GENERIKUS PROGRAMOZÁS Osztálysablonok, Általános felépítésű függvények, Függvénynevek túlterhelése és Függvénysablonok Gyakorlatorientált szoftverfejlesztés C++ nyelven Visual Studio Community fejlesztőkörnyezetben

Részletesebben

III. OOP (objektumok, osztályok)

III. OOP (objektumok, osztályok) III. OOP (objektumok, osztályok) 1. Természetes emberi gondolkozás Az Objektumorientált paradigma alapelvei nagyon hasonlítanak az emberi gondolkozásra. Érdemes ezért elsőként az emberi gondolkozás elveit

Részletesebben

Tömbök kezelése. Példa: Vonalkód ellenőrzőjegyének kiszámítása

Tömbök kezelése. Példa: Vonalkód ellenőrzőjegyének kiszámítása Tömbök kezelése Példa: Vonalkód ellenőrzőjegyének kiszámítása A számokkal jellemzett adatok, pl. személyi szám, adószám, taj-szám, vonalkód, bankszámlaszám esetében az elírásból származó hibát ún. ellenőrző

Részletesebben

Utolsó módosítás:

Utolsó módosítás: Utolsó módosítás: 2011. 09. 08. 1 A tantárggyal kapcsolatos adminisztratív kérdésekkel Micskei Zoltánt keressétek. 2 3 4 5 6 7 8 9 10 11 12 13 14 Erősen buzzword-fertőzött terület, manapság mindent szeretnek

Részletesebben

PHP-MySQL. Adatbázisok gyakorlat

PHP-MySQL. Adatbázisok gyakorlat PHP-MySQL Adatbázisok gyakorlat Weboldalak és adatbázisok Az eddigiek során megismertük, hogyan lehet a PHP segítségével dinamikus weblapokat készíteni. A dinamikus weboldalak az esetek többségében valamilyen

Részletesebben

Bevezetés a programozásba I 10. gyakorlat. C++: alprogramok deklarációja és paraméterátadása

Bevezetés a programozásba I 10. gyakorlat. C++: alprogramok deklarációja és paraméterátadása Pázmány Péter Katolikus Egyetem Információs Technológiai Kar Bevezetés a programozásba I 10. gyakorlat C++: alprogramok deklarációja és paraméterátadása 2011.11.22. Giachetta Roberto groberto@inf.elte.hu

Részletesebben

Algoritmusok és adatszerkezetek gyakorlat 06 Adatszerkezetek

Algoritmusok és adatszerkezetek gyakorlat 06 Adatszerkezetek Algoritmusok és adatszerkezetek gyakorlat 06 Adatszerkezetek Tömb Ugyanolyan típusú elemeket tárol A mérete előre definiált kell legyen és nem lehet megváltoztatni futás során Legyen n a tömb mérete. Ekkor:

Részletesebben

C++ referencia. Izsó Tamás február 17. A C++ nyelvben nagyon sok félreértés van a referenciával kapcsolatban. A Legyakoribb hibák:

C++ referencia. Izsó Tamás február 17. A C++ nyelvben nagyon sok félreértés van a referenciával kapcsolatban. A Legyakoribb hibák: C++ referencia Izsó Tamás 2017. február 17. 1. Bevezetés A C++ nyelvben nagyon sok félreértés van a referenciával kapcsolatban. A Legyakoribb hibák: Sokan összetévesztik a pointerrel. Keveset alkalmazzák

Részletesebben

Fájlszervezés. Adatbázisok tervezése, megvalósítása és menedzselése

Fájlszervezés. Adatbázisok tervezése, megvalósítása és menedzselése Fájlszervezés Adatbázisok tervezése, megvalósítása és menedzselése Célok: gyors lekérdezés, gyors adatmódosítás, minél kisebb tárolási terület. Kezdetek Nincs általánosan legjobb optimalizáció. Az egyik

Részletesebben

Java és web programozás

Java és web programozás Budapesti M szaki Egyetem 2013. október 9. 5. El adás Interface-ek Korábban már említettem az interface-eket. Akkor úgy fogalmaztam, hogy valamilyen tulajdonságot adnak az osztályoknak. A lényegüket talán

Részletesebben

Visual C++ osztály készítése, adattagok, és metódusok, láthatóság, konstruktor, destruktor. Objektum létrehozása, használata, öröklés.

Visual C++ osztály készítése, adattagok, és metódusok, láthatóság, konstruktor, destruktor. Objektum létrehozása, használata, öröklés. Visual C++ osztály készítése, adattagok, és metódusok, láthatóság, konstruktor, destruktor. Objektum létrehozása, használata, öröklés. Az osztály egy olyan típus leíró struktúra, amely tartalmaz adattagokat

Részletesebben

Programozási nyelvek Java

Programozási nyelvek Java Programozási nyelvek Java Kozsik Tamás előadása alapján Készítette: Nagy Krisztián 13. előadás Throwable Error Exception RuntimeException IOException Saját (általában) Nem ellenörzött kivételek (Unchecked

Részletesebben

Java programozási nyelv 6. rész Java a gyakorlatban

Java programozási nyelv 6. rész Java a gyakorlatban Java programozási nyelv 6. rész Java a gyakorlatban Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2004. október A Java programozási nyelv Soós Sándor 1/16 Tartalomjegyzék

Részletesebben

Karbantartás. Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat:

Karbantartás. Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat: Karbantartás Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat: Jelszó módosítása: A felhasználói jelszavunkat módosíthatjuk ebben a menüpontban, a régi jelszavunk megadása után. Általánosan

Részletesebben

Programozási nyelvek Java

Programozási nyelvek Java -en objektumot tárolunk. Automatikus változók Programozási nyelvek Java Kozsik Tamás előadása alapján Készítette: Nagy Krisztián 3. előadás - végrehajtási vermen (execution stack) jönnek létre - alprogramok

Részletesebben

Dokumentáció. 1. Beadandó feladat

Dokumentáció. 1. Beadandó feladat Ballai Brigitta XG3077 gittacska91@gmail.com 2013.11.25. Dokumentáció 1. Beadandó feladat Feladat : A feladat egy kellően bonyolult osztálystruktúra megtervezése és implementálása Java nyelven. Minimális

Részletesebben

Java VI. Miskolci Egyetem Általános Informatikai Tanszék. Utolsó módosítás: Ficsor Lajos. Java VI.: Öröklődés JAVA6 / 1

Java VI. Miskolci Egyetem Általános Informatikai Tanszék. Utolsó módosítás: Ficsor Lajos. Java VI.: Öröklődés JAVA6 / 1 Java VI. Öröklődés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 03. 07. Java VI.: Öröklődés JAVA6 / 1 Egy kis kitérő: az UML UML: Unified Modelling Language Grafikus eszköz objektum

Részletesebben

Ügyviteli rendszerek hatékony fejlesztése Magic Xpa-val mobilos funkciókkal kiegészítve. Oktatók: Fülöp József, Smohai Ferenc, Nagy Csaba

Ügyviteli rendszerek hatékony fejlesztése Magic Xpa-val mobilos funkciókkal kiegészítve. Oktatók: Fülöp József, Smohai Ferenc, Nagy Csaba Ügyviteli rendszerek hatékony fejlesztése Magic Xpa-val mobilos funkciókkal kiegészítve Oktatók: Fülöp József, Smohai Ferenc, Nagy Csaba Programozás alapjai Ha egy adott adattáblára Ctrl + G t nyomunk,

Részletesebben

Osztályok. construct () destruct() $b=new Book(); $b=null; unset ($b); book.php: <?php class Book { private $isbn; public $title;

Osztályok. construct () destruct() $b=new Book(); $b=null; unset ($b); book.php: <?php class Book { private $isbn; public $title; PHP5 objektumok 1 Osztályok class, new book.php: construct () destruct() $b=new Book(); törlés: $b=null; vagy unset ($b); -elnevezési konvenciók private $isbn; public $title; function

Részletesebben

Az importálás folyamata Felhasználói dokumentáció verzió 2.1.

Az importálás folyamata Felhasználói dokumentáció verzió 2.1. Az importálás folyamata Felhasználói dokumentáció verzió 2.1. Budapest, 2008. Változáskezelés Verzió Dátum Változás Pont Cím Oldal 2.1. 2008.01.17. A teljes dokumentáció megváltozott Kiadás: 2008.01.17.

Részletesebben