Download Kövesdán Gábor Szoftverfejlesztés JAVA SE platformon.pdf PDF

TitleKövesdán Gábor Szoftverfejlesztés JAVA SE platformon.pdf
File Size22.6 MB
Total Pages254
Document Text Contents
Page 2

Az Alkinfo sorozat kötetei

Bányász Gábor - Levendovszky Tihamér:
L inux program ozás, 2003.

Albert István, Balássy György, Charaf Hassan, Erdélyi Tibor, Horváth
Ádám, Levendovszky Tihamér, Péteri Szilárd, Rajacsics Tamás:
A .NET Fram ew ork és program ozása, 2004.

Charaf Hassan, Csúcs Gergely, Forstner Bertalan, Marossy Kálmán:
Sym bian alapú szoftverfejlesztés, 2004.

Benedek Zoltán, Levendovszky Tihamér:
S zoftverfejlesztés C++ nyelven, 2007.

Balogh Péter, Berényi Zsolt, Dévai István, Imre Gábor, Soós István,
Tóthfalussy Balázs:
S zoftverfejlesztés Java EE platform on, 2007.

Forstner Bertalan, Ekler Péter, Kelényi Imre:
B evezetés a m obilprogram ozásba. Gyors p rototípus-fejlesztés
P ython és Java nyelven , 2007.

Gál Tibor:
In terfésztechn ikák , 2010.

Ekler Péter, Fehér Marcell, Forstner Bertalan, Kelényi Imre:
A ndroid-alapú szoftverfejlesztés, 2012.

Asztalos Márk, Bányász Gábor, Levendovszky Tihamér:
L inux program ozás, M ásodik, á tdolgozott kiadás, 2012.

Page 127

Az objektumok sorosítása

6.2. Az objektumok sorosítása
Az objektumok sorosítása (serialization) lehetővé teszi, hogy az objektumpéldány tel­
jes állapotát, azaz példányváltozóinak értékét elmentsük, majd egy későbbi időpont­
ban visszaállítsuk. Mindezt a Java nyelv transzparens módon támogatja, a legtöbb
esetben nincs szükség arra, hogy a részletekbe beleavatkozzunk. A következőkben
megismerkedünk a sorosítás működésével.

6.2.1. A sorosítás működése

Az objektumok alapértelmezésben nem sorosíthatók, egyes osztályok ugyanis olyan
információt reprezentálnak, amelyek a program következő futása során már értelmet­
lenek lennének (például a szálakat reprezentáló Thread osztály példányai), vagy biz­
tonsági kockázatot jelentenének (például olyan osztályok, amelyek privilégiumokat
vagy hozzáférési jelszavakat tárolnak). A sorosítható osztályokat ezért explicit módon
meg kell különböztetni. Ez a Serializable interfész implementálásával tehető meg.
Az interfész üres, ún. marker interfész, azaz nem ír elő egyetlen metódust sem, csak
jelzi, hogy az őt megvalósító osztályok sorosíthatók.

A sorosítható osztályokat ezután az ObjectOutputStream és az ObjectlnputStream
osztályokkal tudjuk sorosítani, illetve betölteni. Az ObjectOutputStream konstrukto
ra OutputStream-példányt (lásd 4.5.1. alfejezet) vár. Ez reprezentálja az adatfolya­
mot, amelybe az objektumot sorosítjuk. Ennek típusa lehet például FileOutputStream,
ha az objektum állapotát fájlba akarjuk menteni, vagy ByteArrayOutputStream is,
így a sorosított objektumot egyéb módon is feldolgozhatjuk, például hálózaton is
elküldhetjük. Az ObjectOutputStreambe az objektumot a writeObject() metódussal
írhatjuk ki. A metódus automatikusan kiírja az objektum összes példányváltozóját az
adatfolyamba. Ha az objektum példányváltozói között más objektumok is vannak, ak­
kor ezeknek is sorosíthatóknak kell lenniük, és a sorosítás során ezek is kimentődnek,
végtelen mélységig. Ha van nem sorosítható példányváltozó is, akkor a sorosítás során
NotSerializableException váltódik ki. Ezeket, vagy más példányváltozókat, amelyek
sorosíthatók ugyan, de elmentésük nem fontos, a transient kulcsszóval megjelölve
tranziessé tehetjük. A tranziens változók nem sorosítódnak. A sorosításhoz készült
példaprogram egyszerű határidőnaplót valósít meg. A bejegyzéseket rendezett hal­
mazban tároljuk, majd mentéskor a halmazt fájlba írjuk ki. A kollekciók sorosíthatók,
ha a bennük tárolt elemek mind megvalósítják a Serializable interfészt. Az alábbi
kódrészlet végzi a határidőnapló fájlba írását.

114

Page 128

6. fejezet: Az állapot elmentése

A betöltéshez az ObjectlnputStream osztály használható, ennek konstruktora
InputStream-példányt vár. Ebből olvassa be a sorosított objektumot a readObject()
metódus hívásakor. Általános jellege miatt ez Object típusú referenciát ad vissza,
tehát konvertálni kell. Az alábbi példában beolvassuk a kimentett határidőnaplót.

115

Fontos speciális eset az, amikor az osztály, amelynek példányait sorosítani kívánjuk,
nem sorosítható szülővel rendelkezik. A szülőtől örökölt példányváltozók nem men­
tődnek el, hanem a szülő konstruktora fut le, és azok az inicializálás utáni kezdeti érté­
keiket veszik fel. Mivel a közvetlen szülő konstruktora meghívódik, ezért tulajdonkép­
pen az összes ős konstruktora le fog futni, és a tőlük örökölt példányváltozók eszerint
inicializálódnak. A sorosítható osztály példányváltozóinak értékét az adatfolyamból
olvassuk be, és ezekkel az értékekkel inicializáljuk őket, ezért ennek az osztálynak a
konstruktora nem fut le.

6.2.2. A sorosítás testre szabása

A sorosítás testre szabására kétféle megoldás létezik. Az első továbbra is a szabványos
sorosítási formátumot alkalmazza, és inkább kiegészítések hozzáadására, mintsem
a folyamat teljes megváltoztatására alkalmas. A második módszer esetén egyáltalán
nem támaszkodunk a szabványos sorosítási folyamatra, ezért az teljesen egyedi mó­
don implementálható.

Általában elegendő az első megoldás használata. Két fő esetben van rá szükség,
hogy a sorosítási folyamatot kiegészítsük. Az egyik eset, hogy a szülőosztály nem so­
rosítható, annak néhány példányváltozóját mégis el akarjuk menteni. A másik esetben
a sorosítani kívánt objektumnak olyan példányváltozója van, amely nem sorosítható.
Kézenfekvő megoldás lenne, hogy azt is sorosíthatóvá tegyük, vagy hozzunk létre be­
lőle sorosítható leszármazott osztályt, és helyette ezt használjuk. Ezek a megoldások
azonban nem mindig lehetségesek, elképzelhető ugyanis, hogy az osztály az osztály­
könyvtár része, így nem tudjuk módosítani, vagy final kulcsszóval van megjelölve,
ezért nem lehet belőle leszármazottat létrehozni. Lehetnek más, gyakorlati okai is an­
nak, hogy ezek a megoldások nem alkalmazhatók. Ekkor csak az a megoldás használ­

Similer Documents