Osztály tervezési szempontok és C++ implementációs ajánlások

Átírás

1 Miskolci Egyetem Általános Informatikai Tanszék Osztály tervezési szempontok és C++ implementációs ajánlások Oktatási segédlet Összeállította: Ficsor Lajos Miskolc

2 Tartalomjegyzék 1. Bevezetés Az osztály fogalma Osztályok közötti kapcsolatok Az általánosítás / pontosítás kapcsolat (is-a) A tartalmazás kapcsolat (has-a) Az aggregáció implemetálása A kompozíció implementálása A használat kapcsolat (use) Az osztály interface Az osztály interface fogalma A jól tervezett osztály interface Az osztály interface részei Az elérési függvények Kezelő függvények Általános tervezési szempontok a kezelő függvények megtervezéséhez A konstruktorok tervezési szempontjai Destruktorok tervezési szempontjai Operátorok tervezési szempontjai Az értékadás operátor A függvényhívás operátor A tagfüggvények implementációja A const minősítő használata Konstans tagfüggvények használata Objektumokat lehetőleg hivatkozás szerint adjunk át i

3 6.4. Ne referenciát adjunk vissza, ha objektum szükséges Ne adjuk vissza egy tagfüggvényen belül létrehozott objektum címét Egy tagfüggvény ne adja vissza olyan adattag referenciáját vagy pointerét, amelynek a láthatósága kisebb, mint a függvényé Ne használjunk függvény overloadingban beépített típusokat és pointereket Irodalomjegyzék melléklet: Értékadás, copy konstruktor és destruktor melléklet: Konstans tagfüggvény melléklet: Hivatkozás és érték szerinti paraméterátadás ii

4 1. Bevezetés Egy általános célú programozási nyelv szabályrendszere számos konstrukciót megenged. Egy szintaktikailag helyes (tehát a fordító által elfogadott és technikailag működőképes) program azonban tartalmazhat olyan részleteket, amelyek praktikus szempontok miatt kerülendők. Ezeket (valamint a jól használható konstrukciókat is) a programozók több évtizedes tapasztalatai jelölik ki. Egy szintaktikailag helyes és a gyakorlati tapasztalatok alapján kerülendőnek tartott konstrukciókat sem tartalmazó program már technikai szmepontból megfelelő, azonban még nem biztos, hogy értelmes feladatot old meg. A software fejlesztés feladata viszont épp egy adott, a gyakorlatban felmerült probléma megoldása. Ezért egy nyelv szintaktikai szabályainak ismerete csak szükséges, de nem elégséges feltétele annak, hogy a gyakorlati életben hasznot hajtó alkalmazást készítsünk. Az objektum orientált programozás a progamot a valóság valamely szeletének modelljeként tekinti. Ezért egy osztály megtervezése és implementálása olyan meggondolásokat is igényel, amelyek nem egyszerűen csak a C++ nyelv szabályainak alkalmazását jelentik. Ebben a részben tehát nem szintaktikai szabályokat fogunk ismertetni, hanem arra próbálunk példákat adni, hogy hogyan lehet jól használható, és az objektum orientált szemléletmódot tükröző osztályokat tervezni. Azaz: hogyan érdemes a C++ nyelv lehetőségeit használni. 2. Az osztály fogalma Az osztály programozástechnikai szempontból egy típus. Programtervezési szempontból az osztály a valóság valamely fogalmának modellje. Az objektum orientált programokban alapvetően kétféle osztályokat használunk: követlenül az alkalamazási terület (application domain) fogalmait modellező osztályok a feladat megoldásához technikailag szükséges implementációs osztályok. Az alkalmazási terület osztályai modellezhetnek felhasználói fogalmakat (például teherautó), felhasználói fogalmak általánosításait (például jármű). Az implementációs osztályok lehetnek az alábbiak modelljei: hardware / software erőforrások (például memória, i/o stb.) 1

5 más osztályok implementálásához szükséges osztályok (például listák, vermek) beépített adattípusok és vezérlési szerkezetek 3. Osztályok közötti kapcsolatok Az osztályok tervezése során foglalkozni kell az egyes osztályok közötti kapcsolatokkal. Az osztályok között a modellezés szempontjából különböző jellegű logikai kapcsolatok lehetnek (Általánosítás-pontosítás, tartalmazás, használat stb). Ugyanakkor a C++ nyelv biztosít olyan nyelvi szerkezeteket, amelyek implementációs kapcsolatokat teremtenek az osztályok között. Az osztály implementációja során az egyik feladat a logikai kapcsolatok leképezése ezekre a nyelvi szerkezetekre. 3.1 Az általánosítás / pontosítás kapcsolat (is-a) Implementációja a public leszármaztatás. Ez a kapcsolat azt jelenti, hogy egy leszármazott objektum minden szempontból úgy viselkedik, mint egy ős objektum, (azaz egy leszármazott objektum egyben mindig ős objektum is), de ez fordítva nem igaz. Egyszerű példa: class CSzemely class CHallgato : public CSzemely void sortiszik(const CSzemely& sz); void feladatotbead(cont CHallgato& h); Ezután CHallgato nagypista; CSzemely kispista; sortiszik(kispista); // OK // OK, mert egy Hallgato egyben Szemely is sortiszik(nagypista) // Hibás, mert egy Szemely nem biztos, hogy Hallgato is feladatotbead(kispista); Vigyázni kell azonban, mert a természetes nyelv nem mindig fogalmaz pontosan. Erre egy gyakran emlegetett tanpélda: class CMadar public: void repul(void); 2

6 class CStrucc : public CMadar Ebben az esetben a CStrucc osztály örökli a repülés képességét a CMadar osztálytól. A félreértést nyilván az okozza, hogy a "A madár tud repülni" mondat nem azt jelenti, hogy "Minden madár tud repülni", hanem azt, hogy "A madarak általában tudnak repülni". Egy lehetséges javítása a fenti példának az alábbi: class CMadar public: CKaja MitEszik(void); Bool TudRepulni(void); class Cstrucc : public CMadar Ebben az esetben a CStrucc osztály csak a repülés lehetőségét örökli a CMadar osztálytól, ami közelebb van a valóságos viszonyokhoz. Egy talán pontosabb javítás: class CMadar public: CKaja MitEszik( void ) ; ; class CGyalogMadar : public CMadar ; class CRendesMadar : public CMadar public : void Repul( void ) ; ; class CStrucc : public CGyalogMadar ; class CSas : public CRendesMadar ; Ez a megoldás pontosabban tükrözi azt a tényt, hogy vannak repülni tudó és repülésre képtelen madarak is A tartalmazás kapcsolat (has-a) Kétféle tartalmazás jellegű kapcsolatot különböztethetünk meg: aggregáció: a rész az egészhez tartozik, de önállóan is létező entitás kompozíció: a rész önmagában nem létezhet, csak valaminek a részeként Az aggregáció implemetálása Lehetséges megoldások: 3

7 a tag objektum pointere vagy referenciája a tartalmazó osztályban Hátránya, hogy szoros a kapcsolat a tartalmazó és a tartalmazott objektum között. Biztosítani kell a konzisztenciát, hiszen például a tartalmazott objektum megszűnése a rá vonatkozó pointer vagy referencia érvénytelenné válását jelenti. A tartalmazott private leszármaztatása a tartalmazó osztályból Ennek a megoldásnak a hátránya az, hogy a tartalmazott önálló voltát csak osztály szinten fejezi ki A kompozíció implementálása Lehetséges megoldások: tag objektum a tartalmazott osztályban lokális osztálydefiníció a tartalmazott számára 3.3. A használat kapcsolat (use) Osztályok az alábbi módokon használhatják egymást: CX használja a CY nevet (feltételezi, hogy CY deklarált a használat helyén) o adattag típusaként o tagfüggvény visszatérési értékének vagy paramétereinek típusaként CX használja a CY osztályt (láthatósági szabályok alapján) o meghívja a CY egy tagfüggvényét o írja/olvassa a CY egy adattagját CX létrehoz egy CY típusú objektumot o statikus definíció o dinamikus definíció CX veszi CY méretét A használat kapcsolat implementálásának alapvető problémája, hogy csak közvetett nyelvi eszközök jelzik az ilyen kapcsolatokat 4

8 Korlátozó tényezők: azonosítók lexikális érvényességi tartománya osztály tagjainak láthatósági attribútumai 4. Az osztály interface Az osztályokat úgy kell megtervezni, hogy azokat az interface-ük segítségével lehessen használni, anélkül, hogy az adattagok implementációjáról bármit is kellene tudni. Egy osztály megtervezése során gondolni kell arra, hogy azt bázisosztályként esetleg most még gondolatban sem létező osztályok is fogják használni. Ezért törekedni kell arra, hogy az esetleges leszármazott osztályokról csak a legszükségesebbeket tételezzük fel, és hogy egy leszármazott osztály tervezése során ne legyen szükség a bázisosztály implementációs részleteinek ismeretére (hiszen ez nem is biztos, hogy rendelkezésre áll) Az osztály interface fogalma Egy osztály interface-e szűkebb értelemben a public tagfüggvényeinek összessége. Ezt kell ismernie az osztály használójának Tágabb értelemben ide számíthatjuk C++ programok esetén a friend függvényeket és osztályokat is. Ezt a lehetőséget azonban csak feltétlenül szükséges esetben használjuk, mert ellentmond az információ rejtés alapelvének A leszármazott osztályok számára még az osztály interface-ét képezik a protected függvények és adattagok is.ezzel is mértékletesen kell bánni, mert implementációs függést hoz létre az ős és a leszármazott osztály között A jól tervezett osztály interface A jó interface az alábbi három alapvető követelménynek kell megfeleljen: Legyen teljes, azaz minden olyan funkciót valósítson meg, amely az adott osztálytól elvárható (függetlenül attól, hogy a jelen alkalmazás során szükségesnek látszik-e). Az osztályt tehát funkció-orientáltan és ne az adott felhasználás szempontjából vizsgáljuk. Ezzel egyrészt újrafelhasználható elemeket alkotunk, másrészt nem korlátozzuk magunkat hiányzó funkciókkal a program további tervezése - készítése során. Legyen minimális, azaz ne legyen az interface része olyan funkció, amely a külső felhasználó számára érdektelen. Az adott osztály belső használatára szánt függvények legyenek mindig private (esetleg a leszármazott osztályokra is gondolva protected) módúak. Ezzel egyben megkönnyítjük az osztály esetleges áttervezését is: az adattagok és a segédfüggvények implementációjának módosítása a felhasználó program egyetlen pontján sem jelent változást. 5

9 Legyen kezelhető méretű. Ha a teljesség követelményének betartása túlságosan sok funkció megvalósítását eredményezi, az az osztály használójának munkáját nehezíti. (Egy programozó általában legfeljebb néhány tíz tagfüggvényt tart kezelhetőnek egy osztályon belül.) A sok funkció között nagyobb valószínűséggel lesznek hasonlóak, ami pedig könnyen vezet az egyes funkciók tényleges feladatának félreértéséhez. A terjedelmes interface mindig tervezési hibára utal, a két leggyakoribb ok: olyan funkciókat is az interface részének ítéltünk, amelyek inkább belső funkciók az osztály határait nem jól állapítottuk meg, és túl sok feladatot akarunk rábízni. A helyes architektúra kialakítása érdekében az eredetileg tervezett osztályt több osztályra kell bontani, és ezek között leszármaztatással vagy más mechanizmussal megteremteni a kapcsolatot Az osztály interface részei A public tagfüggvényeket funkciójuk szerint az alábbi csoportokba sorolhatjuk: kezelő függvények Idetartoznak az inicializáló, értékadó, konverziós stb. függvények, amelyeket sokszor nem is direkt módon a programozó aktivizál, hanem a fordítóprogram implicite hív meg. elérési függvények Az adattagok értékének elérésére vagy azok értékének módosítására. munkavégző függvények Az osztály lényegi funkcióit aktivizáló függvények. Míg a munkavégző függvények természetesen osztály-specifikusak, az első két csoportba tartozó függvények a különböző osztályok esetén is számos hasonlóságot mutatnak, előállításuk részben automatizálható is. 4.4 Az elérési függvények Az elérési függvények általában egyszerűek, implementálásuk értelemszerű. Segítségükkel az információ rejtés elvének megsértése nélkül tesszük használhatóvá az osztály objektumainak adattagjait. A kezelő fügvények megírása többletmunkát jelent, használatuk azonban a következő előnyöket biztosítja: Szabályozhatjuk azon adatok körét, amelyekhez egyáltalán hozzáférést biztosítunk az osztály objektumait használó program számára. 6

10 Szabályozhatjuk az egyes adattagok használatának módját (csak az értékét felhasználni, csak beállítani, vagy mindkét műveletre van-e módja a programnak). A függvények elrejtik a programozó elől az adattagok belső ábrázolásának implementációs részleteit, ezért ha azt megváltoztatjuk, az osztályt használó programban nem kell változtatni, ha ugyanolyan formában adjuk vissza a értéket. Például ha egy egész értéket ad vissza az alérési függvény, a felhasználó programozó számára lényegtelen, hogy az ténylegesen egy egész típusú adattag értéke, vagy esetleg egy bonyolult adatbázis lekérdezés eredménye. Természetesen, ha az adat tárlosi módja jelentősen eltér az elérési függvény által mutatott formátumtól, a megfelelő transzformációt biztosító függvény implementálása komoly programozói munkát is jelenthet. A kezelő függvényeket sok esetben a fejlesztő eszközök automatikusan generálni képesek, csökkentve ezzel az osztályt implementáló programozó munkáját. 5. Kezelő függvények Egy osztály interface-ének megtervezése során a kezelő függvények kialakítása az osztály használhatóságát alapvetően befolyásolja, sőt egyes kezelő függvények hiánya vagy helytelen implementációja a jól implementált munkavégző függvények ellenére is programhibákhoz vagy hibás működéshez vezethet. Ezért minden osztály tervezése során célszerű átgondolni ezek tervezési kérdéseit. Ebben a fejezetben tárgyalunk néhány általános szempontot, majd az egyes kezelő függvény típusok helyes megtervezéséhez szükséges speciális implementációs kérdésekkel foglalkozunk Általános tervezési szempontok a kezelő függvények megtervezéséhez Az alábbi kérdések megvizsgálása segíti a jól tervezett, ezért kényelmesen felhasználható és korrekt működést biztosító osztályok létrehozását. 1. Hogyan kell az objektumoknak létrejönniük és megszűnniük? A válasz alapvetően befolyásolja a konstruktorok számát, paraméterlistájukat, a desktruktorok működését illetve a new és delete operátorok esetleges átdefiniálásának szükségességét. 2. Miben különbözik egy objektum inicializálása és értékadása? A konstruktorok és az értékadó operátorok működése. 3. Milyen kezdőállapoto(ka)t vehet fel egy objektum a keletkezése után? A kezdőállapot beállítása többnyire a konstruktorok feladata, de valamennyi 7

11 tagfüggvény implementációját befolyásolja, hogy milyen állapotot tételezhet fel, illetve köteles ellenőrizni. 4. Hogyan történik az objektumok érték szerinti átadása? A másoló konstruktor tervezéséhez. 5. Milyen legális értékeket vehet fel az osztály egy objektuma? A tagfüggvények hibaellenőrzését befolyásolja. 6. Van bázisosztálya az új osztálynak? Ha igen, a tervezés egyik fontos célja, hogy eldöntse, mely funkciók örökölhetők változatlanul a bázisosztálytól, és vannak-e a bázisosztályban olyan virtuális függvények, amelyeket át kell definiálni. 7. Lesz-e várhatóan az osztálynak leszármazott osztálya? Mely tagfüggvények, esetleg adattagok legyenek protected minősítésűek, illetve melyek azok a funkciók, amelyeket a leszármazott osztályoknak át kell definiálni, azaz itt virtuálisnak célszerű minősíteni? 8. Milyen típusú konverziók megengedettek, illetve hasznosak? Legyünk fegyelemmel arra, hogy az általunk deklarált konverziós operátorokat a fordító a szükséges helyzetekben implicite (kifejezett kérésünk nélkül) is használni fogja. Ezt elkerülhetjük azáltal, hogy bizonyos konverziókat egyszerű tagfüggvények formájában fogalmazunk meg. Külön érdemes gondolni arra, hogy az egyoperandusú konstruktor egyben konverziós operátor is! 9. Milyen operátorok definiálása lehet hasznos az osztály használatában? Az operátor overloading tervezéséhez. A felhasználó számára nem ajánlott, de az osztály implementációja számára hasznos operátorok definiálhatók private (esetleg protected) minősítéssel. 10. Miknek lehet szüksége a nem public tagok elérésére? El kell dönteni, hogy mely adattagokat és tagfüggvényeket célszerű protected minősítéssel ellátni, illetve mely osztályok illetve külső függvények kaphatják meg a friend minősítést. Mivel ezek a döntések az információ rejtésnek ellentmondó konstrukciókat eredményeznek, mindig gondosan elemzedő a szükségességük. Különösen érdemes átgondolni, hogy a public adattag használata valóban elkerülhetetlen-e? A fenti általános szempontok és az egyes kezelő függvény típusokra vonatkozó speciális nyelvi szabályok figyelembevételével a továbbiakban a legfontosabb kezelő függvények tervezési és implementációs szempontjairól ejtünk néhány szót. 8

12 5.2. A konstruktorok tervezési szempontjai Néhány nagyon egyszerű osztálytól eltekintve konstrukrorra mindig szükség van. A konstruktor-készlet kialakítása során elsősorban a felhasználás kényelme a legfontosabb szempont, a működésüket azonban az határoza meg, hogy milyen legális kezdőállapotba kell kerülnie az általa inicializált objektumnak. Gyakran csökkenthetjük a szükséges konstruktorok számát az alapértelmezett értékekkel ellátott paraméterlista használatával. Ebben az esetben gondosan érdemes megválasztani a paraméterek sorrendjét: minél valószínűbb, hogy aktuális paraméternek megfelel az alapértelmezés szerinti érték, annál hátrébb kerüljön a paraméterlistán. Gondoljunk arra is, hogy a konstruktornak konverziós szerepe is van. Mivel a fordítóprogram a konverziót automatikusan alkalmazza minden, a nyelv szabályai szerint számára előírt szituációban, ha egy konstruktor konverzióra nem alkalmas, használjuk az explicit kulcsszót. Ne feledjük továbbá azt sem, hogy bizonyos esetekben az alapértelmezés szerinti konstruktor hívódik meg, ezért szükséges lehet annak átdefiniálása is az osztály sajátosságainak megfelelően. A konstruktorok speciális esete a copy konstruktor. Mindig gondoljuk meg, hogy nincs-e szükség ennek definiálására, főleg a mutató típusú adattagokat tartalmazó, az adattagokon kívül dinamikusan foglalt memóriaterületeket is használó osztályok esetében. 5.3 Destruktorok tervezési szempontjai A destruktor fontos feladata minden olyan "mellékhatás" eltüntetése, amelyet a konstruktorhívás és a munkavégző függvények hívásai okoztak. A leggyakoribb talán az, hogy a konstruktor vagy valamelyik másik tagfüggvény memóriaterületeket allokál, amelyeknek felszabadításáról itt kell gondoskodni. A destruktor írásánál gondolni kell arra, hogy bármelyik konstruktor által létrehozott és bármilyen (legális) állapotban levő objektum esetén jól működjön. Ez nem mindig egyszerű feladat. Ha kell, használjuk egy olyan adattagot, amelynek vizsgálatával eldönthető, hogy melyik konstruktor által létrehozott és milyen állapotban lévő objektumról van szó. Ha bázisosztályként is használandó vagy használható osztályt tervezünk, gondoljuk meg, hogy a destruktornak nem kell-e virtuálisnak lennie. Ebben az esetben az ebből az osztályból származtatott valamennyi osztály destruktora is virtuális lesz (bár nevük természetesen nem egyezik meg), és a virtuális függvényekre vonatkozó szabályok szerint hívódnak meg. Ez azt eredményezi, hogy egy bázisosztály típusú mutatóval megcímzett objektumot akarunk megszüntetni, a megszüntetendő objektum aktuális típusához tartozó destruktor hívódik meg. Ellenkező esetben még akkor is a bázisosztály destruktora hívódik, ha a leszármazot osztály rendelkezik destruktorral, ez pedig nyilvánvalóan hibákhoz vezethet. 9

13 A bázisosztályban elvileg a virtuális destruktor valódi virtuális függvénynek is definiálható, ez azonban gondot okozhat akkor, ha egy leszármazott osztálynak nincs destruktora (hiszen az akkor a valódi virtuális függvényt örökli). Ez tehát kényszeríti a leszármazott osztályokat arra, hogy mindenképpen definiáljanak destruktort. Ha ezt el akarjuk kerülni, a szokásos megoldás: ha a bázisosztálynak nincs szüksége destruktorra, definiáljunk egy üres törzsű függvényt. Ezekután minden leszármazott osztály esetén szabadon eldönthető, hogy átdefiniáljuk-e ezt az implementációt Operátorok tervezési szempontjai Bár nem mindig tagfüggvénnyel történik a definiálásuk, az osztályokhoz hozzátartoznak az átdefiniált operátorok is. Alapszabályként azt mondhatjuk, hogy minden olyan operátort definiálni kell, ami az adott osztály használata során természetesnek tűnik. (Ez sokszor csak egy, már megírt tagfüggvény hívását jelenti.) Az operátor implementálása során legyünk figyelemmel arra, hogy amit egy programozó természetesnek tarthat, azt valósítsuk is meg. (Például egy, jelentéséből következően kommutatív művelet esetén mindkét típusösszetétel használható legyen, ha egy relációs operátort megvalósítottunk, akkor az összest implementáljuk stb.) Tervezési hiba, ha egy átértelmezett operátor jelentése az adott kontextusban a programozó számára nem egyértelmű. Ilyenkor valószínűleg egy jól megválasztott nevű tagfüggvény alkalmazása a jó döntés. Kölönösen problémás egy, az operátor eredeti jelentésének ellentmondó jelentés definiálása Az értékadás operátor Az operátorok közül különleges szerepe van az = (értékadó) operátornak. Ha copy konstruktorra szükség volt, akkor szükség van az azonos osztálytípusú objektumok közötti értékadás átdefiniálására is. Ne feledjük, hogy az értékadás műveletének is van eredménye, tehát az operátor= függvénynek a baloldali operandus értékével kell visszatérnie! Azonos típusú objektumok közötti értékadás operátorát átdefiniáló függvény helyes prototípusa tehát egy COsztaly osztályra: const COsztaly& operator= (const Cosztaly& ); Azt sem szabad elfelejtenünk, hogy az értékadó operátornak az a = a típusú értékadó kifejezés esetén is jól kell működnie. Megvizsgálva a copy konstruktor, az értékadás és a destruktor feladatát, nagyon sok osztály esetén ezek a funkciók tartalmaznak két olyan műveletet, amelyeket azonosan kell implementálni: az adattagok által használt memóriaterület felszabadítása ("destroy") az adattagok másolása egyik objektumból a másikba ("copy"). 10

14 Ezeket a műveleteket célszerű egy-egy private tagfüggvény alakjában implementálni. Ez egyrészt a kód egyszerűsítését jelenti, másrészt biztosítja, hogy ezek a folyamatok minden szükséges helyen egységesen hajtódjanak végre. A fentiek megvalósítása esetén a fenti három funkció az alábbiak szerint implementálható: copy konstruktor: "copy" értékadás: "destroy" + "copy" destruktor: "destroy" Az 1. mellékletben szereplő példa (cppex27.cpp) szemlélteti az értékadó operátor helyes implementációját A függvényhívás operátor Nagyon sokszor hívott funkcióra kényelmes megoldás lehet a () - függvényhívásoperátor - átdefiniálása, mert akkor az objektum neve után írt paraméterlistával aktivizálható, megspórolva a tagfüggvény nevét. (Egyben azonban el is vesztve azt az információt, amit a név hordoz!). 6. A tagfüggvények implementációja A C++ nyelv számos olyan szintaktikailag helyes konstrukciót enged meg, amelyek bizonyos helyzetekben mégis a program hibás vagy nem hatékony működését eredményezhetik. Célszerű tehát az eddigi programozási tapasztalatok tanulságaként bizonyos konstrukciókat előnyben részesíteni, másokat elkerülni, illetve bizonyosak pontos jelentését átgondolni. A továbbiakban néhány ilyen szituációra hívjuk fel a figyelmet. 3.1 A const minősítő használata Alapszabályként rögzíthetjük le, hogy mindenütt, ahol csak lehet, használjunk const minősítőt. Ez egyrészt segít a fordítóprogramnak a típuseltérések detektálásában, ezáltal számos futási időben bekövetkező hiba helyett szintaktikai hibajelzést kaphatunk, másrészt számos esetben hatékonyabb kódot eredményez, mint arra a fejezet további részeiben láthatunk példákat. A konstansok definiálására a fentiek figyelembevételével soha de makródefiníciót, hanem const minősítésű inicializált változót használjunk, mert ilyenkor a konstans minden egyes használata esetén a fordítóprogramnak módja van típusellenőrzésre. 11

15 6.2 Konstans tagfüggvények használata Minden olyan tagfüggvényt, amely nem változtatja meg az objektum állapotát, deklaráljunk konstans tagfüggvényként. A deklaráció mind az osztály felhasználóját, mind a fordítóprogramot informálja. Konstans objektumra csak konstans tagfüggvény hívható meg. Ha egy tagfüggvényből létezik const minősítésű és minősítetlen változat is, const objektumra const tagfüggvény hívódik meg. Ez különösen hasznos lehet abban az esetben, ha a konstans objektumra a függvénynek másképpen kell működnie. Az, hogy egy tagfüggvény definíciója nem tartalmaz olyan utasítást, amely valamely adattag értékét közvetlenül megváltoztatja, még nem jelenti azt, hogy valamilyen közvetettebb módon nem változhat az objektum állapota a használatával. Egy tagfüggvény számára a const minősítés megadásához gyakran nem elegendő a definíciójának a formális vizsgálata, hanem a működésének a funkcionális elemzése szükséges. Lássunk erre egy egyszerű példát a String osztály egy lehetséges (most leegyszerűsített) implementációja segítségével. (A teljes példa - cppex29.cpp - a 2. mellékletben található.) class CString1 char* m_pchelemek; public: CString1(const char* szoveg); ~CString1(void); char& operator[] (const int index) const; void kiir(void) const; ; // Latszolag konstans tagfuggveny, mert nincs // benne ertekadas egy adattagra sem char& CString1::operator[] (const int index) const return m_pchelemek[index]; // Ez egy igazi const tagfuggveny void CString1::kiir(void) const cout << m_pchelemek << "\n"; A fenti definíció alapján írhatók a következő utasítások: const CString1 nevem("ficsor"); cout << nevem[2] << "\n"; /* OK! */ 12

16 /* A forditoprogram szamara OK, mert const tagfuggvenyt hivunk meg const objektumra */ nevem[0] = 'X'; A nevem[2] kifejezés korrekt, hiszen egy konstans string egy elemének az értékét használom fel. A másik kifejezés viszont bár a fordítóprogram számára legális - egy konstans objektum állapotának megváltoztatását okozza (a nevem objektum ezután a "Xicsor" stringet tartalmazza), funkcionálisan tehát hibás! A problémát látszólag megoldhatjuk azzal, hogy "elvesszük" a const minősítést az operator[] függvénytől, az alábbiak szerint: class CString2 char* m_pchelemek; public: CString2(const char* szoveg); ~CString2(void); char& operator[] (const int index); void kiir(void) const; ; /* Nem minositjunk const-nak, mert tudjuk, hogy kozvetve kepes megvaltoztatni az objektumot */ char& CString2::operator[] (const int index) return m_pchelemek[index]; Ebben az esetben viszont az egyébként korrekt const CString2 nevem("ficsor"); cout << nevem[2] << "\n"; /* OK! */ utasítások okoznak gondot a fordítóprogram számára, hiszen egy const objektumra nem const tagfüggvényt próbáltunk meghívni. A probléma azzal oldható meg, ha külön változatot definiálunk az operator[] függvényből a konstans és a nem konstans objektumok számára, az alábbiak szerint: class CString3 char* m_pchelemek; 13

17 public: CString3(const char* szoveg); ~CString3(void); char& operator[] (const int index); const char& operator[] (const int index) const; void kiir(void) const; ; /* Nem konstans objektumokra meghivodo verzio */ char& CString3::operator[] (const int index) return m_pchelemek[index]; /* Konstans objektumokra meghivodo verzio */ const char& CString3::operator[] (const int index) const return m_pchelemek[index]; Ezzel a definícióval minden esetben korrekt módon működik az alábbi programrészlet: CString3 szoveg("szoveg"); /* Korrekt, a char& operator[] (const int index); hivodik meg */ szoveg[0] = 'S'; const CString3 en("ficsor"); /* Korrekt: a const char& operator[] (const int index) const; valtozat hivodik meg, ezert hibajelzest kapunk es az objektum nem valtozik meg */ en[0] = 'S'; A második esetben a hibajelzést az okozza, hogy az értékadás baloldalán a const char& típusú függvényérték áll, és a fordítóprogram képes jelezni egy konstans érték referencián keresztül megkísérelt megváltoztatását. 14

18 6.3. Objektumokat lehetőleg hivatkozás szerint adjunk át Az érték szerint átadott paraméterek és visszatérési érték sokszor felesleges konstruktor és copy konstruktor hívásokkal (és esetleg ezekhez kapcsolódóan destruktor hívásokkal) lassítják a program futását. Példaként tételezzük fel az alábbi (egyszerűsített) osztálydefiníciókat: (Teljes példa a 3. mellékletben található cppex30.cpp.) class CString private: char* m_pchelemek; public: CString(const char* szoveg); CString(const CString& szoveg); ~CString(void); ; class CSzemely CString m_nev; CString m_cim; public: CSzemely(const CString& neve, const CString& cime); CSzemely (const CSzemely& masik); ~CSzemely(void); ; és az alábbi függvénydefiníciókat: CSzemely szemelyvissza1(cszemely sz) return sz; CSzemely& szemelyvissza2(cszemely& sz) return sz; Ha az első függvényváltozatot meghívjuk, az alábbiak szerint: cout << "en objektum letrehozasa\n"; CSzemely en("ficsor", "Miskolc"); cout << "\nvissza objektum letrehozasa\n"; szemely vissza("",""); 15

19 cout << "\nfuggveny hivasa ertek szerinti atadassal\n"; vissza = szemelyvissza1(en); a program futása alapján előállított alábbi táblázat szerint 13 implicit függvényhívás történik: Fuggveny hivasa ertek szerinti atadassal String copy konstruktor String copy konstruktor Szemely copy konstruktor String copy konstruktor String copy konstruktor Szemely copy konstruktor Szemely ertekado operator Szemely destruktor String destruktor String destruktor Szemely destruktor String destruktor String destruktor A formális paraméter inicializálása az aktuális paraméterrel A return utasítás végeredménye inicializál egy ideiglenes objektumot A függvényértéket tartalmazó ideiglenes objektum és a vissza változó közötti értékadás Megszűnik a formális paraméter Megszűnik a függvény visszatérési értékét tároló ideiglenes objektum Ezzel szemben ha mind a paraméter, mind a visszatérési érték hivatkozás típusú, csak az értékadó operátor hívására kerül sor. Megjegyzés: Ha kipróbáljuk a mellékelt programkódot, nem feltétlenül ugyanezt a sorrendet kapjuk (a függvényhívások száma azonban mindig ugyanannyi lesz). Ennek a magyarázata az, hogy a formális paraméterek, mint lokális változók és a függvényérték visszaadása során használt ideiglenes ojektum megszüntetésének sorrendje az alkalmazott fordítóprogramtól függhet Ne referenciát adjunk vissza, ha objektum szükséges Bár az előző pont azt sugallja, hogy használjunk mindig referencia típusú visszatérési értéket a függvényekre, ez sem igaz. Például két komplex szám összeadásának eredménye egy komplex érték, itt nem tudjuk a művelet eredményét tároló ideiglenes objektum létrejöttét és az azt kísérő konstruktor-destruktor hívást megspórolni. Ha megkíséreljük, a következő pontban vázolt problémába ütközünk. 16

20 6.5 Ne adjuk vissza egy tagfüggvényen belül létrehozott objektum címét A komplex számok összeadásának helyes implementációja az előző pontban elmondottak szerint: class CKomplex double m_valos; double m_kepzetes; public: CKomplex(double v, double k); CKomplex operator+(const Komplex& masik) return CKomplex(m_valos + masik.m_valos, m_kepzetes + masik.m_kepzetes); Ha megkíséreljük a referencia típusú visszatérési értéket alkalmazni, az alábbi (hibás!!) implementációhoz juthatunk: CKomplex& operator+(const CKomplex& masik) CKomplex eredmeny(m_valos + masik.m_valos, m_kepzetes + m_masik.kepzetes); return eredmeny Ebben az esetben a visszatérési érték egy olyan értékre hivatkozó referencia, amely a függvény lefutása után már nem létezik, hiszen lokális változó volt. Így a referencia érvénytelen. Próbálhatunk ezen javítani azzal, hogy dinamikusan foglalunk helyet az eredménynek: CKomplex& operator+(const CKomplex& masik) CKomplex* eredmeny = CKomplex (m_valos + masik.m_valos, m_kepzetes + masik.m_kepzetes); return *eredmeny Mivel a dinamikusan lefoglalt memóriaterület nem szűnik meg a függvényből való kilépéskor, a prolémát látszólag megoldottunk. Azonban helyére egy új probléma lép: éppen az, ami a megoldást adná - a memóriaterület nem szűnik meg, hanem valakinek majd meg kell szüntetnie. Erre pedig még az sem elég, ha a programozónak felhívjuk a figyelmét erre a tényre. mert egy összeadás eredménye gyakran (mint részeredmény) egy ideiglenes változóban tárolódik, amelynek címe a programozó számára elérhetetlen. 17

21 Végül megjegyezzük, hogy ráadásul az eredeti célt (az eredmény tárolására szolgáló ideiglenes változó létrehozásához szükséges konstruktorhívás elhagyását) a fenti veszélyes megoldások nem is érik el Egy tagfüggvény ne adja vissza olyan adattag referenciáját vagy pointerét, amelynek a láthatósága kisebb, mint a függvényé Világos, hogy ha ezt megtesszük, akkor ezzel a védett adattag elérését a védelem ellenére is széles közben elérhetővé tesszük. Egy egyszerű példa: class CString private: char* m_pchelemek; public: CString(const char* szoveg); CString(const CString& szoveg); // Hibas implementáció!!!! operator char* () (return m_pchelemek; ~CString(void); ; Ebben az esetben például egy CString a char* mutato = a; utasítás után a mutato pointeren keresztül korlátozás nélkül elérhetjük az a objektum eredetileg private adataagját Ne használjunk függvény overloadingban beépített típusokat és pointereket A hívás és a definíciók paraméterszignatúrájának egyeztetése során, ha a fordítóprogram nem talál pontos típusegyezést, végrehajthat standard típuskonverziókat. Ez a mechanizmus bár elvileg pontosan definiált a programozó számára nehezen átlátható, ezért használata nem javasolt. A típuskonverziók végrehajtása után ráadásul több "ugyanannyira egyező" definíciót is találhat a fordítóprogram, ami pedig fordítási hibát okoz. 18

22 7. Irodalomjegyzék Az alább felsorolt könyvekben amelyeket a jelen segédlet készítése során magam is felhasználtam a témára vonatkozó számos további információ található. Bjarne Stroustrup: A C++ progamozási nyelv Kiskapu Kiadó/ Addison-Wesley, Budapest, Scott Meyers: Hatékony C++ (50 jó tanács programjaink és programterveink javítására) Scolar Kiadó, Budapest, 2003 Bruce Eckel: Thinking In C++, 2 nd edition, Volume 1 Prentice Hall, 2000 Elérhető elektronikus formában a szerző honlapjáról ( illetve a tanszéki szerveren található tükrözésről: 19

23 1. melléklet: Értékadás, copy konstruktor és destruktor // CPPEX27.CPP // Ertekadas es copy konstruktor kialakitasa // A peldaban nem implementalt tagfuggvenyek prototipusai kommentben #include <iostream.h> #include <string.h> class CSzemely char* m_pchnev; char* m_pchszulhely; int m_nszulev; public: // konstruktorok CSzemely (char* n, char* h, int ev); // CSzemely (void); // Default helyett CSzemely (const CSzemely& masik); // Copy konstruktor // destruktor ~CSzemely(void); // ertekadas const CSzemely& operator=(const CSzemely& masik); // eleresi fuggvenyek // void neve(char* n); // void hely(char* h); // void ev(int e); // const char* mianneve(void) const; // const char* miahhely(void) const; // const int mikorszuletett(void) const; // Itt kovetkezhetnek a munkavegzo fuggvenyek // private: // segedfuggvenyek char* masol(const char* masik); void copy(cszemely const& masik); void destroy(void); ; // Az egyes tagfuggvenyek implementalasa // // Segedfuggvenyek char* CSzemely::masol(const char* masik) int i=strlen(masik); char* tmp = new char[i+1]; strcpy (tmp, masik); return tmp; void CSzemely::copy(CSzemely const& masik) // Feltetlen masolas. (Persze helycsinalassal...) m_pchnev = masol(masik.m_pchnev); m_pchszulhely = masol(masik.m_pchszulhely); m_nszulev = masik.m_nszulev; void CSzemely::destroy(void) delete m_pchnev; delete m_pchszulhely; m_nszulev = 0; // Konstruktor 20

24 CSzemely::CSzemely (char* n, char* h, int ev) cout << "konstruktor!" << endl; m_pchnev = masol(n); m_pchszulhely = masol(h); m_nszulev = ev; // copy konstruktor CSzemely::CSzemely (const CSzemely& masik) cout << "copy konstruktor!" << endl; copy(masik); // destruktor CSzemely::~CSzemely(void) cout << "destruktor!" << endl; destroy(); // Ertekadas azonos tipussal const CSzemely& CSzemely::operator=(const CSzemely& masik) cout << "ertekadas!" << endl; // csak ha nem azonos a ket objektum if (this!= &masik) destroy(); copy(masik); return *this; int main(void) CSzemely valaki("nev","hely",1960); // konstruktorhivas CSzemely masvalaki=valaki; // copy konstruktor hivasa masvalaki = valaki; // ertekado operator hivasa return 0; // Eredmeny: //konstruktor! //copy konstruktor! //ertekadas! //destruktor! //destruktor! 21

25 2. melléklet: Konstans tagfüggvény // CPPEX29.CPP #include <string.h> #include <iostream.h> // //Konstans tagfuggvenyek hasznalata // class CString1 char* m_pchelemek; public: CString1(const char* szoveg); ~CString1(void); char& operator[] (const int index) const; void kiir(void) const; ; CString1::CString1(const char* szoveg) m_pchelemek = new char[strlen(szoveg) + 1]; strcpy(m_pchelemek, szoveg); CString1::~CString1(void) delete [] m_pchelemek; // Latszolag konstans tagfuggveny, mert nincs // benne ertekadas egy adattagra sem char& CString1::operator[] (const int index) const return m_pchelemek[index]; // Ez egy igazi const tagfuggveny void CString1::kiir(void) const cout << m_pchelemek << "\n"; // Legyen az operator[] nem const tagfuggveny class CString2 char* m_pchelemek; public: CString2(const char* szoveg); ~CString2(void); char& operator[] (const int index); void kiir(void) const; ; 22

26 CString2::CString2(const char* szoveg) m_pchelemek = new char[strlen(szoveg) + 1]; strcpy(m_pchelemek, szoveg); CString2::~CString2(void) delete [] m_pchelemek; // Nem minositjunk const-nak, mert // tudjuk, hogy kozvetve kepes megvaltoztatni // az objektumot char& CString2::operator[] (const int index) return m_pchelemek[index]; // Ez egy igazi const tagfuggveny void CString2::kiir(void) const cout << m_pchelemek << "\n"; ; // Kulon verzio a konstans es a nem // konstans objektumokra class CString3 char* m_pchelemek; public: CString3(const char* szoveg); ~CString3(void); char& operator[] (const int index); const char& operator[] (const int index) const; void kiir(void) const; ; CString3::CString3(const char* szoveg) m_pchelemek = new char[strlen(szoveg) + 1]; strcpy(m_pchelemek, szoveg); CString3::~CString3(void) delete [] m_pchelemek; ; // Nem konstans objektumokra meghivodo verzio char& CString3::operator[] (const int index) return m_pchelemek[index]; // Konstans objektumokra meghivodo verzio const char& CString3::operator[] (const int index) const return m_pchelemek[index]; 23

27 // Ez egy igazi const tagfuggveny void CString3::kiir(void) const cout << m_pchelemek << "\n"; int main() // Elso verzio: az indexeles op. constans taggfuggveny const CString1 nevem("ficsor"); cout << nevem[2] << "\n"; // OK! // A forditoprogram szamara OK, mert const // tagfuggvenyt hivunk meg const objektumra nevem[0] = 'X'; // Eredmeny: a const objektum megvaltozott, // a tagfgv visszateresi ertekenek felhasznalasaval. // A forditoprogram ezt nem tudja detektalni! nevem.kiir(); // Masodik verzio: az indexeles op. // nem konstans tagfuggveny const CString2 nev("ficsor"); // A forditoprogram szamara nem OK, mert // nem const tagfuggvenyt hivunk meg const objektumra. // Pedig ez legalis hasznalat // Kiprobalhato, ha az utasitas kommentjet eltavolitjuk // cout << nev[2] << "\n"; // OK! // A forditoprogram szamara nem OK, mert // nem const tagfuggvenyt hivunk meg // const objektumra. // Most igaza van, ez nem legalis. // Kiprobalhato, ha az utasitas kommentjet eltavolitjuk // nev[0] = 'X'; nev.kiir(); // Harmadik verzio: az indexeles op.-nak // kulon verzioja van a konstans es a // nem konstans objektumokra. CString3 szoveg("szoveg"); // Korrekt, a // // char& operator[] (const int index); // hivodik meg szoveg[0] = 'S'; 24

28 const CString3 en("ficsor"); // Korrekt: a // const char& operator[] (const int index) const; // valtozat hivodik meg, ezert hibajelzest kapunk // es az objektum nem valtozik meg // Kiprobalhato, ha az utasitas kommentjet eltavolitjuk // en[0] = 'S'; return 0; 25

29 3. melléklet: Hivatkozás és érték szerinti paraméterátadás // CPPEX30.CPP #include <iostream.h> #include <string.h> // Ertek szerinti parameteratadas // Keszitette: Ficsor Lajos class CString private: char* m_pchelemek; // Segedfuggveny void masol(const char* szoveg); public: // Konstruktor CString(const char* szoveg); // Copy konstruktor CString(const CString& szoveg); // Destruktor ~CString(void); ; void CString::masol(const char* szoveg) m_pchelemek = new char[strlen(szoveg) + 1]; strcpy(m_pchelemek, szoveg); CString::CString(const char* szoveg) cout << "String konstruktor" << "\n"; masol(szoveg); CString::CString(const CString& szoveg) cout << "String copy konstruktor" << "\n"; masol(szoveg.m_pchelemek); CString::~CString(void) cout << "String destruktor" << "\n"; delete m_pchelemek; class CSzemely CString m_nev; CString m_cim; public: CSzemely(const CString& neve, const CString& cime); 26

30 CSzemely (const CSzemely& masik); const CSzemely& operator=(const CSzemely& masik); ~CSzemely(void); ; CSzemely::CSzemely(const CString& neve, const CString& cime): m_nev(neve), m_cim(cime) cout << "Szemely konstruktor" << "\n"; CSzemely::CSzemely(const CSzemely& masik): m_nev(masik.m_nev), m_cim(masik.m_cim) cout << "Szemely copy konstruktor" << "\n"; CSzemely::~CSzemely(void) cout << "Szemely destruktor" << "\n"; const CSzemely& CSzemely::operator=(const CSzemely& masik) // FIGYELEM! Ez most nincs implementalva!!!!! cout << "Szemely ertekado operator" << "\n"; return *this; // Kulso fuggvenyek CSzemely szemelyvissza1(cszemely sz) return sz; CSzemely& szemelyvissza2(cszemely& sz) return sz; int main() cout << "en objektum letrehozasa\n"; CSzemely en("ficsor", "Miskolc"); cout << "\nvissza objektum letrehozasa\n"; CSzemely vissza("",""); cout << "\nfuggveny hivasa ertek szerinti atadassal\n"; vissza = szemelyvissza1(en); cout << "\nfuggveny hivasa hivatkozas szerinti atadassal\n"; vissza = szemelyvissza2(en); cout << "\nprogram vege\n"; return 0; // Futaseredmeny: 27

31 //en objektum letrehozasa //String konstruktor //String konstruktor //String copy konstruktor //String copy konstruktor //Szemely konstruktor //String destruktor //String destruktor // //vissza objektum letrehozasa //String konstruktor //String konstruktor //String copy konstruktor //String copy konstruktor //Szemely konstruktor //String destruktor //String destruktor // //Fuggveny hivasa ertek szerinti atadassal //String copy konstruktor //String copy konstruktor //Szemely copy konstruktor //String copy konstruktor //String copy konstruktor //Szemely copy konstruktor //Szemely ertekado operator //Szemely destruktor //String destruktor //String destruktor //Szemely destruktor //String destruktor //String destruktor // //Fuggveny hivasa hivatkozas szerinti atadassal //Szemely ertekado operator // //Program vege //Szemely destruktor //String destruktor //String destruktor //Szemely destruktor //String destruktor //String destruktor 28