4. PROGRAMOZÁSI PARADIGMÁK, PROGRAMOZÁSI NYELVEK

4. PROGRAMOZÁSI PARADIGMÁK, PROGRAMOZÁSI NYELVEK

Bizonyára elgondolkodott már a nyájas olvasó, miért van annyi programozási nyelv a világon. Szerény becslések szerint csak a használatban lévő programozási nyelvek száma meghaladja a 4000-et. Vajon mi az oka ennek? A számítástechnikai szakembereknek az a hajlama, hogy minden probléma számítógépes megoldására a legmegfelelőbb programozási nyelvet kívánják használni, s miután a megoldandó problémák száma meglehetősen nagy, a programozási nyelvek száma is nagyra nőtt? Vagy egyszerűen a profit, a haszonszerzés, azaz, hogy újabb és újabb programozási nyelveket, fejlesztő rendszereket szeretnének eladni? Valóban szükség van ennyi nyelvre? Különböznek a programozási nyelvek oly mértékben, hogy azok valóban mások és mások? Nos, szabványosításra sokkal kevesebb nyelv került, mint amennyit használtak már a történelemben. Továbbá, az utóbbi időben már lassabbodott a nyelvek számának rohamos növekedése. A szoftver krízis, a minőség iránti igény növekedése, és ebből fakadóan a szoftver újrafelhasználás gondolatkör eredményezték ezt a lassulást. Mindenesetre, szeretnénk rendet csinálni ebben a nyelvi Bábelben. Szeretnénk a nyelveket áttekinteni, osztályozni. Szerencsénkre a programozási nyelvek szimbólumkészleténél, megjelenésénél, még a nyelvtani szabályainál is sokkal fontosabbak a „nyelv mögötti gondolatok”. Ezek maradandóbbak, kevésbé változatosak, tovább élnek. A mögöttes gondolatok és elképzelések megismerése segíti a számítástechnikával ismerkedőket, hogy egy-két nyelv elsajátítása után már nem jelent gondot egy-egy újabb programozási nyelv akár önerőből való megtanulása sem.

4.1. A PROGRAMOZÁSI PARADIGMA FOGALOM 4.1.1. Egy kis történelem, paradigma váltások … A programozási nyelvek történetét együtt szokás tárgyalni a hardver fejlődéssel és a működtető rendszerek fejlődési trendjével. Kétségtelen az összefüggés

2

PROGRAMOZÁSI PARADIGMÁK

ezek között, most mégis kíséreljük meg a programozási nyelvek, a programozási módszerek fejlődését áttekinteni. Bal és Grune [Bal&Grune, 1994] évtizedeket különböztet és nevez meg e históriában. A múlt század negyvenes évei képezték a „nyelvnélküli” világot. A számítógép tervezők, építők, a felhasználók még ugyanazon a személyek voltak, a gépi programozást még assembly fejlesztő rendszer sem segítette. Az ötvenes években már voltak számítógép gyártó és tőlük különböző felhasználó intézmények, de a hardveres és szoftveres feladatkörök, a rendszerprogramozói, programozói és felhasználói munkakör még nem vált szét. Már növekedett a gépek teljesítménye, de az igen szűk kapacitások miatt a számítógépes művészet csúcsa a minél kisebb, minél hatékonyabb kód megírása volt. Megjelent az assembly és a Fortran nyelv. A hatvanas években kezdtek a nyelvek sokasodni. Már nem volt akkora gond a számítási erő, a memória – persze, nem a mai viszonyokhoz kell ezeket hasonlítani. A programok kifejező ereje növekedett, ez a jellemzője a kornak. A hetvenes években jelentkezett a szoftver krízis. A programok túlnyomó része nem futott, gondok voltak a program helyességgel, a gépfüggetlenséggel. A nyolcvanas években megkíséreltek válaszolni a kihívásokra. Strukturált programozás paradigmája volt a válasz. A kilencvenes évek paradigmája, alapja az objektum orientáltság. Máig nagy a hatása, bár a mai időket a Web programozás paradigma jellemzi. Érdemes pillantást vetni az évtizedek „egysoros” jellemzésére: 40-es évek 50-es évek 60-as évek 70-es évek 80-as évek 90-es évek Ma

A nyelvnélküli világ: ha egy program fut, az jó program Használd ki! Meg tudod írni egy instrukcióval kevesebbel? Kifejező erő! Nézd, ez az egysoros program mit meg nem csinál! Csökkentsd a gépfüggőséget! Nézd a program helyességét! A komplexitás a gond. Strukturált programozás. A szoftver újra felhasználás. Objektum orientált a világ. Web programozás.

Amit hangsúlyozni szeretnék itt, az a következő, a programozási nyelvek fejlődését ún. paradigmaváltások kísérték. A fejlődési szakaszokat különböző paradigmák alapozták meg. Ha osztályozni akarjuk a programozási nyelveket, akkor a „mögöttes gondolatukat” meghatározó programozási paradigmák szerinti osztályozás jó gondolat lehet. Persze, hogy megértsük ezt az osztályozást, nézzük meg, mit is jelent számunkra a paradigma kifejezés.

4.1.2. A paradigma fogalma A paradigma kifejezésnek hosszú története van. A tudománytörténet során jelentése változott. A jelentése attól is függ, hogy milyen tudományterületre alkal-


3

mazzuk. Érdemes tehát meghatározni, hogyan is fogjuk mi értelmezni ebben a tárgyban. A paradigma kifejezés két ógörög szóból származik. Egyik szó a para (elnézést kérek, hogy nem a görög ábécét használom itt), jelentése körülbelül az, hogy hasonló, vagy egymásra utalt, vagy egymásmelletti. A paralelogramma szavunk első két szótagjáról van itt szó. A másik görög szó a deigma. Jelentése kb. „ami be van mutatva”. A paradeigma ógörög kifejezés a piacokon egymás mellett bemutatott árucikkeket jelentette. Volt egy olyan értelme, hogy bemutatási példány, bemutatási példa. Még mindig az ógörögöknél maradva, ahol a tanulás-tanítás módszere példák felsorolása volt, a paradigma kifejezés olyan értelmet nyert, hogy oktatási céllal bemutatott példát, példázatot jelent a paradigma szó. A társadalomtudományokban ma is felfedezhető ez a fajta jelentés. A természettudományokban azonban jelentésváltozáson ment át a szó. A tanítási példa jelentés helyett inkább az elméletet igazoló példa jelentést kezdte felvenni. A középkorban pl. a bolygók mozgásával igazolták a mechanikai törvényszerűségeket. A bolygók mozgásának paradigmája volt az elmélet igazolása. Egyegy jól választott példa az elmélet és módszer bizonyítása volt. A mai paradigma definíció – a természettudományok területén is – megtartva az eredetéből a minta, a mintául szolgálás mozzanatot, gazdagodott. Az idegen szavak szótára három jelentését adja. A paradigma bizonyításra, vagy összehasonlításra alkalmazott példa lehet (ez az eddigi levezetésünkből adódik), vagy ragozási minta lehet (ebben is szerepel a minta gondolata, de ez egy szűkített jelentés), illetve „az adott korszakban elfogadott általános tudományos tételek együttese; a kor tudományos világképe”. Utóbbit a társadalomtudományok használják, és túl általános a jelentésük. A mi meghatározásunkhoz közelítve két mai definíciót idézek. Az egyik [Erdélyi et al, 1997] szerint a paradigma olyan átfogó szabályok, adatok és adatstruktúrák együttese, amely összetett, dinamikus tevékenységi kör számára mintául szolgál. Követése jó (vagy nem túl rossz) döntések meghozását segíti. A másik [Kuhn, 1970] szerint a paradigma koherens módszerek együttese, mely összetett problémakör kezelését hatékonnyá teszi, azzal, hogy mintául szolgál. A definíciók jók, használhatók. Talán azzal lehetne ezeket kiegészíteni, hogy paradigma olyan összefüggő módszerek, szabályok és adatok együttese, melyek követése, használata hatékony lehet egy adott probléma tartomány adott problémájának megoldására. A paradigmák jellemezhetők, megragadhatók egy nagyon egyszerű, de roppant kifejező erejű princípiummal. Ez a jellemző egyszerűen megfogalmazható és a paradigmának meggyőző erőt adhat. A kifejező erejű alapelv mellett természetesen kellenek módszerek és technikák is, melyek persze nem mondhatnak ellent a röviden megfogalmazott alapelvnek. Miért jók, miért szükségesek a paradigmák? Nos, a bonyolult rendszereket nagyon nehéz modellezni. Főleg ott, ahol az ember is része a rendszernek, ahol emberi döntésekre is szükség van, a modellezés és determinisztikus optimalizálás lehetetlen. Meggyőző mintákat követve azonban juthatunk eredményre. Gond is van persze, ha paradigmákat követve akarunk megoldani problémákat. Egyik gond a túlegyszerűsítés kísértése. Miután a paradigmát jellemzi az a bizo-

4


nyos meggyőző erejű, egyszerű alapelv, követése során hajlamosak lehetünk a túlzott egyszerűsítésre, egysíkú magyarázatokra. Ennek a veszélynek mindig tudatában kell lennünk. A másik gond az, hogy egy paradigma csakis akkor mondható paradigmának, ha van legalább néhány követője. A paradigmát, a jellemző alapelvét el kell fogadni. Kell, hogy legyenek követői, támogatói a paradigmának. A paradigma valóban meggyőző kell legyen.

4.1.3. Programozási paradigmák A programozás ma még emberi tevékenység. Mint emberi tevékenység, meglehetősen bonyolult. Lehet bizonyos mértékig modellezni, tervezni, de, mivel emberek programoznak, determinisztikus modellezése biztosan lehetetlen. Paradigmák szerinti megközelítése – azaz programozási minták, módszerek és technikák követése szerinti – ígéretes lehet. Szokták is ezért tárgyalni a programozási paradigmákat. Szuromi Zsolt [Szuromi,1996] például egy sor programozási paradigmát tárgyal. Szerinte van monolitikus programozás, strukturált programozás, imperatív programozás, applikatív programozás, objektum orientált programozás, konkurens programozás. Mi, jelen tárgyban az imperatív, a funkcionális, a logikai és az objektum orientált programozás paradigmáit tárgyaljuk. Az imperatív program lényege az, hogy lépésenként végrehajtott módú, teljesen specifikált és kontrollált manipulációkat adjunk meg a programban, teljesen specifikált (névvel ellátott) adatokon (fully specified and fully controlled manipulation of named data in step-wise fashion). A funkcionális programozás során a programozó inkább azt specifikálja a programban, mit kell kiszámítani, nem az, hogy hogyan, milyen lépésekben. (Kifejezésekből álló) függvények hívásából, ezek kiértékeléséből áll a program. Nincsenek állapotok, mellékhatások (nem számít, mikor, csak az melyik függvényt hívjuk). (Referential transparency.) Nincs értékadás, csak érték-kiszámítás. A logikai programozási paradigma szerint a programozó if-then szabályokat és tényeket fogalmaz meg, és a rendszer automatikusan kikövetkezteti (infer) ebből, hogy egy adott feltétel igaz-e vagy sem. Ha a tényekből és a szabályokból az következtethető ki (automatikusan), hogy a feltétel igaz, akkor ez a feltétel bizonyított (proved). Az objektum orientált programozás paradigmája nem is egyszerűen követendő programozási stílus, hanem tervezési módszer, modellezési módszer, szemléletmód is egyben. Ebben az adatmodell és az eljárásmodell szétválaszthatatlan (egységbezárás). Az újrafelhasználhatóság elvét kiterjeszti, ameddig csak lehetséges (öröklődés). Az információrejtés és szabályozott elérés a programozás minőségét növeli. A többalakúság teszi lehetővé, hogy ugyanarra az üzenetre a különböző objektumok a saját módjukon válaszoljanak. Miután összefoglaltuk a tárgyalandó paradigmák lényegét, nézzük a paradigmákat részletesen!


5

4.2. AZ IMPERATÍV PROGRAMOZÁSI PARADIGMA Az imperatív programozási stílus alakult ki a számítástechnika történetében legelőször. Ennek számos oka volt. A Neumann elvű gépek programozásának ez a stílus felel meg igazán, máig ez a programozási módszer a leghatékonyabb, a nyugati ember gondolkodásmódjának nagyon megfelel ez a programozás. Miután a kezdetben tisztán Neumann elvű számítógépek voltak, és sok tekintetben a mai gépek is ennek az elvnek felelnek meg, nem csodálható az imperatív paradigma kezdeti és bizonyos területeken a mai sikere. Voltak ugyan kísérletek idővel, hogy változtassanak az imperatív programozás elsöprő fölényén, a Prolog törekvések, vagy a japánok ötödik generációs számítógép rendszere ilyenek voltak, de nem hoztak áttörést ezek a kísérletek. Véleményem szerint ennek elsődleges oka a teljesítmény előny: egy imperatív program sokszorosan gyorsabb, kisebb hardver kapacitással megelégszik. Manapság az objektum orientált programozási paradigma kél versenyre az imperatív párjával. Valószínű az OOP térnyerése, azonban az imperatív nyelveket teljességgel sohasem fogja kiszorítani. Az imperatív programokra kisebb hardver kapacitásoknál mindig szükség lesz. Mikor az imperatív programozás jelentőségét ennyire hangsúlyozom, természetesen nem akarom lebecsülni a többi programozási paradigmát. Mindegyiknek meg lehet találni a saját problémakörét, azt a problémakört, melyben az adott paradigma hozhatja az optimális eredményt (ahol az optimum kritérium nem valószínű, hogy a gyorsaság lesz). Az imperatív programban lépésenként megadják, hogy mit kell tenni és milyen adatokkal. Pongyolán fogalmazva, olyan egy imperatív program, mind a szakácskönyv. Először felsorolják a hozzávalókat (deklarációkkal teljes specifikációt adnak az adatokról), majd lépésekben megadják az eljárást, mit kel tenni először, hogyan kell folytatni a dolgot, esetleg ismételni kell valamely lépéseket, esetleg választani kell, hogyan is folytassuk a munkát. Ez a fajta „program”, egy tevékenységsorozat leírása, megadása az atlanti embertípustól nem idegen. Ismét komolyra fordítva a szót, az imperatív paradigmának nagyon sok programnyelv megfelel. Csak néhányat említek meg a legjelentősebb és legelterjedtebb imperatív nyelvek közül. Elsőnek a C nyelvet, de imperatív jellegű az ADA, a Pascal, a Modula-2, a különféle Basic nyelvjárások, és a még ma is használatos FORTRAN és COBOL is e családba tartozik. És említsük meg, hogy a objektum orientált programnyelvek – bár mást hangsúlyoznak, mint a tedd ezt, utána ezt és ezt lépéseket – belül megtartottak sokat az imperatív gondolatból. Metódusaik belül lépésenkénti teendőket tartalmaznak. Mint említettük, az imperatív paradigma alakult ki történelmileg először. A gépi kódú programozásról – ahol a hardver egyre magasabb szintű absztrahálásáról volt csak szó – áttérve a magasabb szintű nyelvekre egyre többet kezdtek foglalkozni az adat-típusokkal és a programvezérlés menetével. Beláthatjuk, hogy az imperatív paradigma éppen az adattípusokat és a vezérlés menetét próbálja megragadni.

6


Foglaljuk össze röviden és velősen az imperatív paradigma lényegét, hiszen ha paradigma a koncepció, akkor meg lehet fogalmazni röviden és meggyőzően ezt a lényeget.

4.2.1. A paradigma Az imperatív paradigma szerint egy programban teljesen specifikált nevezett adatokon lépésenkénti végrehajtással adottak a teljesen specifikált manipulációk. Figyeljük meg, a definícióban három dolgot jelentettünk ki. Az első (amit fent a harmadikként jelentettünk ki) az, hogy teljesen specifikáltak az adatkezelési manipulációk, számítások, döntések. Minden utasítás, operáció előre megadott, rögzítettek a környezeti feltételei, adott az értelmezése. Másodszor azt jelentettük ki, hogy a manipulációk lépesekként vannak megadva. Ez a gondolat a programok vezérlési szerkezeteire hívja fel a figyelmet. Az utasítások végrehajtása lépésenként lehet soros egymásutániság (szekvenciális programszerkezetek), lehetnek ismételt lépések (ciklusok, ciklikus végrehajtási szerkezetek), és lehetnek választások a következő lépésre, melyik utasítás legyen a következő (elágazásos szerkezetek). A lépésenkénti utasítások, a „tedd ezt, utána ezt és ezt” jelleg adta a paradigma nevét: imperatív = parancsoló. Harmadszor (a definíciónkban ez volt az első) pedig azt mondtuk, hogy teljesen specifikált nevezett adatokon fognak történni a manipulációk. Nos, itt tehetünk engedményeket. A paradigma lényegének összefoglalása ebben szigorúbb, mint a paradigmának azért megfelelő valódi programozási nyelvek többsége. Azaz vannak nyelvek, melyek nem követelik meg a szigorú tipizálást (a teljes specifikációt), engedik a névnélküli adathasználatot (lexikális konstansokat). Az adatok specifikálását a programban a deklarációkkal tehetjük meg: Deklarációkkal adjuk meg a nevüket és a típusukat. A legtöbb az imperatív családba tartozó nyelv a változók deklarációját megköveteli a rájuk való első hivatkozás előtt. A változók ezzel nevet és típust nyernek. A típusuk meghatározza az értéktartományukat és a velük hiba nélkül végezhető operációkat. A program futtatásához az értéktartományuknak is megfelelő tárolási reprezentációt kell meghatározni. A tárolási reprezentáció mikéntje meg fogja adni memória helyfoglalás méretét is. Azok a nyelvek, melyek engedik az automatikus változódeklarációt (pl. ilyen a FORTRAN) valójában szintén biztosítják a teljes adatspecifikációt. Legfeljebb nem a programozó deklarálja ezeket a változókat, azok automatikusan deklarálódnak. Az általános vélemény szerint ez a kis programozónak adott kényelmi engedély meglehetősen nagy hibaforrás. A lexikális konstansok típusa szintén „automatikusan deklarált”., azaz a szövegkörnyezetből kideríthető. Ellentmondások persze itt is előfordulhatnak, növelve a programozói hibák előfordulásának lehetőségét, de a legtöbb nyelv létrehozója engedi a lexikális konstansok használatát a nyelvében. A továbbiakban két mozzanattal foglakozunk: a deklarációk-adatok világával és a programvezérlési szerkezetekkel. Nézzük ezeket sorban.


7

4.2.2. Az adat deklarációkhoz A data (adatok) egy gyűjtőnév. Az adatok az információ hordozói. Az imperatív programozási nyelvekben az adatoknak van típusa. A típus tulajdonképpen egyfajta osztályozás (klasszifikáció). A legtöbb adatnak van neve, és a nevüket használjuk az adatokkal való manipulációkban. Az adatok a memóriában foglalnak helyet, ezért kell legyen címük a memóriában. Végül, minden adatnak van pillanatnyi értéke. Miután a memória változtatható, az adat értéke alapértelemben cserélhető. Ha a programozási nyelv engedi ezt a változtatást, akkor hívhatjuk ezt a nevezett adatot változónak. Az adatok típusa több mindent meghatároz. Megadja az adat felvehető értékkészletét, az adattal végezhető operációk készletét. Rendszerint a típus megadja a memóriabeli reprezentációt (a bitelrendezést, struktúrát) is, ezzel a memóriabeli helyfoglalási hosszat. Egy példán szeretném bemutatni a név, a típus, a reprezentáció és az érték között (4.1. ábra). Az ábrán az int típushoz tartozó értékkészlet és operációkészlet adott. E két attribútum a nyelvhez kapcsolódik, rendszerint a nyelv alkotói határozzák meg. A memóriabeli reprezentációt már a fordítóprogram írói is befolyásolhatják: rendszerint az adott hardverhez igazítva adják meg. Az ábránkon egy szokásos reprezentációt adunk: 16 bites helyfoglalással egy szavas egész számára. Az első bit az előjel bit, a többi a bináris kódolással adja az egész értéket. Az ábránkon az i változóhoz ezt az int típust rendeltük. Az i változó pillanatnyi értékét adó bitminta a 4 pillanatnyi értéket adja. Típus Típus név int

Változó név i

…, -1, 0, 1, 2, …

Értékkészlet Operációkészlet Reprezentáció

s

215

Bitminta

0

0

+, -, *, /, … … 22 …

1

21

20

0

0

4.1. ábra. Kapcsolat a név, a típus, a reprezentáció és az érték között Az imperatív nyelvekben az adatokat deklarálni kell. A deklaráció az adatokhoz nevet és típust kapcsol (binds a name and type). Ezzel az adat ismertté válik. A puszta deklaráció (allusion) csak ismertté teszi az adatot. A definíciós deklaráció ismertté és használhatóvá teszi az adatot, azzal, hogy az adathoz memóriabeli címet is kapcsol. A legtöbb imperatív nyelvben lehetséges típus definíció is. Ez a definíció egy típushoz kapcsol nevet, amivel a típus válik ismertté és használhatóvá. Ne feledjük, hogy egy típus mindig megadja az értékkészletet és az operációkészletet, nos, egy típus definíciónál -- lehet persze, hogy nem kifejezetten, hanem csak beleértetten -- megadandó e két készlet.

8


Tovább is általánosíthatunk! Egy nyelvben létezhet valamilyen entitás1 deklaráció (ami ismertté tesz az entitást), illetve entitás definíció (ami használhatóvá is teszi az entitást. Az entitás szót használom itt, bár használhatnánk az objektum kifejezést is. Az utóbbit azonban az objektum orientált programozási paradigmának megfelelő nyelvek foglalják, ezért nem akarok keveredést. Az entitás az imperatív nyelvekben lehet név, típus, adat, operáció, rutin (eljárás vagy függvény) is. Hangsúlyozom, hogy az egyszerű deklaráció ismertté tesz egy entitást, míg a definíció használhatóvá is teszi azt. Előfordulhat, hogy a deklaráció egyben definíció is, de lehet előbb pusztán deklarálni, majd később definiálni ugyanazt az entitást. A leggyakoribb és legegyszerűbb példa erre a „késleltetett” definícióra az eljárások függvények deklarációja, definíciója. Gyakori ugyanis, hogy egy deklarált függvény – aminek ismerjük a nevét és típusát -- definícióját nem is mi, a program írói adjuk meg, hanem az majd a futtatható program összeállításánál (a linkelés során) definiálódik a rutin. Úgy is szoktuk mondani, hogy a linkelés során oldódnak fel bizonyos függvénynevek. A 4.2. ábrán bemutatok két imperatív nyelvi változó deklaráció programrészletet. Az egyik nyelv az ismert C nyelv, a másik az ADA nyelv (ami szintaxisában nagyon hasonlít a Pascal nyelvre). C nyelv int i, j; int k=4, j=4;

ADA nyelv I, J: Integer; K, L: Integer:=4;

4.2. ábra. Változó deklarációk A deklarációkban négy változót deklarálunk, az i, j, k és l változókat. Ne feledjük a deklaráció többes feladatát, azaz, hogy készíteni kell típusos adatot és definíciós deklaráció esetén memóriát kell allokálni neki, illetve, hogy kötni kell egy nevet a változóhoz! A definíciós deklarációk megengedik a változó feltöltését kezdeti értékekkel. Az ábrán az i és j (Az ADA nyelvben I és J) változók biztos kaptak nevet és típust. A k és (K és L) változók pedig, miután inicializáljuk is őket, biztos, hogy definiálódnak is. Úgy is mondhatjuk, hogy a definíciós deklarációkkal példányosítunk egy adott típust. Érdekes, hogy az ALGOL 68 nyelv szétválasztja a név és típus kapcsolást és a memória hely allokálást! A 4.3. ábrán a k változó definíciójában a „ref int k” kapcsolja a nevet és típust, míg a „loc int” allokálja a memóriahelyet. A „:= 4” szerkezet pedig kezdeti értéket ad a definiált változónak.

1

Entitás: lényeges létező valami


9

Algol 68 ref int k = (loc int := 4);

4.3. ábra Deklaráció az Algol 68-ban A legtöbb imperatív programnyelv megengedi a szövegkörnyezeti konstansokat (literális konstansok, literálok). Ezek névnélküli, de típussal és címmel rendelkező adatok, azaz ismert az érték- és operáció készletük, valamint a reprezentációjuk is. Mivel nincs nevük, egyszeri a hivatkozás rájuk: pillanatnyi értéküket adják ott, ahol a szövegben szerepelnek. Mind a típusuk és pillanatnyi értékük a szövegkörnyezetből deríthető ki, a fordítóprogramok a szövegből ismerik fel a literálokat. A fordító biztosít számukra memóriát is. A literálok címét rendszerint nem is érhetjük el programjainkban, szemben a névvel rendelkező entitásokkal: ezek címét – legalább is némely programozási nyelvben – elérhetjük. Némely nyelv megengedi a konstansok deklarációját is (4.4. ábra). Ez tulajdonképpen inicializációs (ezzel definíciós) „változó” deklaráció, ahol is a fordítóprogram külön szoftveres védelmet biztosít, nem engedi a konstans „változót” módosítani. Vagy azzal a megoldással, hogy bár a hardver képes lenne a módosításra, de nem engednek olyan kódot, ami módosítana, vagy eleve írásvédett memória szekcióba helyezik az ilyen „változót”. C nyelv const int k=4, j=4;

ADA nyelv K, L: Constant Integer:=4;

4.4. ábra Konstans deklarációk A konstans deklarációk előnye, hogy hibalehetőségeket kerülhetünk el: fegyelmezettebb programozási stílus alakítható ki, ha minden adatot kifejezetten deklarálunk, a szövegben nem maradnak literális konstansok. Érdemes foglakozni az iniciálizálatlan változók problémájával. Több nyelv – a C és az ADA is – engedi, hogy memóriát foglaljunk, ugyanakkor kezdeti értéket kifejezetten ne adjunk változóknak. A kérdés az, hogy megjósolható-e ilyenkor a változó kezdeti értéke? Hibát okozhat ez a bizonytalanság. A nyelvek fejlesztői különböző válaszokat adhatnak. A legegyszerűbb – bár nem elegáns – válasz az, hogy a programozóra hárítják a felelősséget. Másik válasz szerint minden típushoz tartozik egy speciális, a nyelv fejlesztői által adott inicializáló érték, és a kifejezett kezdeti értékadás nélküli deklaráció során ezt az értéket veszi fel a változó. Egy harmadik válasz szerint egyes típusú változók automatikusan felveszik a speciális inicializáló értéket, mások pedig nem, azok „titokban” inicializálódnak. Tulajdonképpen ismét a programozóé minden felelősség, ráadásul még a könnyelműségre csábítják is. A „titokban” inicializálódás” azt is jelentheti, hogy egy változó a neki allokált memóriaterületen maradt, nem törölt bitmin-

10


tázat szerint kapja a kezdeti értéket. Súlyos biztonsági kockázatot jelent ez. Végül, lehetséges – bár „költséges” megoldás, ha a fordítóprogram figyelmeztet, tiltakozik a kifejezetten inicializálatlanul maradt deklarációk miatt. A nevek világához, a névtérhez kapcsolódó probléma a helyettesítő (alias) nevek használata, illetve a névtúlterhelés (over-loading) kérdésköre. Az újranevezés, vagyis a helyettesítő nevek használatának engedélyezése több programnyelvben lehetséges. A lényege ennek az, hogy új nevet kötünk egy már létező, névvel is rendelkező entitáshoz. Alias nevet adunk neki. A 4.5. ábrán ADA nyelvi példákat mutatok be. Itt a korábban definiált I változó K néven is elérhető, illetve a korábban definiált A tömb középső elemére Kozepso néven is hivatkozhatunk. ADA K: Integer renames I; Kozepso: Integer renames A((N+M)/2);

4.5. ábra Újranevezés Egyes nyelvek az újranevezést nem minden entitásra engedik. Például típusnevekre kockázatos lehet az újranevezés, típusegyezőségi gondok léphetnek fel. A szigorúan vagy szigorúbban típusellenőrző nyelvek a típusnév újranevezést ezért nem engedik (pl. az ADA sem engedi). Az újranevezési lehetőség hozhat kényelmet a programozónak. Vannak azonban kockázatai, növeli a hibalehetőségeket. Személy szerint nehezen tudom eldönteni, vajon jó koncepció-e az „aliasing”. Ha úgy tetszik, az „aliasing” ellentéte a név túlterhelés: ugyanazt a nevet kapcsoljuk különböző entitásokhoz. Veszélye nem kíván sok magyarázatot, az entitásokra való hivatkozások összekeverése lehet eredmény. Teljes elkerülése szinte lehetetlen. Gondoljunk csak az operátorok túlterhelésére, ott az „over-loading” egészen természetes! Inkább az okozna gondot, ha külön egész összeadó és lebegőpontos összeadó + operátor lenne a nyelvekben! Az ADA nyelvben meglehetősen sok túlterhelés van, a C-ben is van, bár kevesebb, a C++ ismét növeli a túlterhelési lehetőségeket. Térjünk vissza a típusokhoz! Általában a hardver – legalább is a mai hardverek – három alap-típust támogatnak. Ezek az egész típusok, különböző bitszélességekben, a különböző méretű és pontosságú lebegőpontos típusokat, végül a karakteres, vagy szöveglánc típusokat. Éppen ezért ezek a típusok nyelvekben is létező, előre definiált alap-típusok. A nyelvekben persze további változatok is lehetnek. A C-ben pl. a karakter típus kifejezetten létezik, de az egy 8 bites szélességű előjeltelen egészként is viselkedhet, azaz egy rövid integrálisként. Vannak nyelvek, melyek kezelik a logikai (boolean) típust is, és ismét vannak, melyek a különböző típusú entitások címére mutató pointer típust is.


11

Miután a típus – többek között – értékhalmaz is, az üres halmaznak is megfelelhet típus! A C nyelvben ilyen típus a void típus! Nem minden nyelvben ismeretes hasonló típus! A nyelvek fejlesztői biztosítanak néhány – különböző szélességű és pontosságú – skalár alaptípust. Biztosítanak továbbá típus konstruktor mechanizmusokat, melyekkel a programozó új, akár összetett típusokat hozhat létre. A létrehozott új típusoknak akár nevet is adhat (ajánlott a hibalehetőségek csökkentése miatt, ebben is az olvashatóság könnyítése2 miatt). A leggyakoribb típuskonstruálások a következők: Felsorolásos típus létrehozása (mikor is nem már meglévő típusból konstruálunk újat); Tömb típus készítése (beleértve az egy- vagy többdimenziós tömböket, a társtömböket); Lista típus előállítása (a funkcionális nyelvek egyik legfontosabb típusa ez, ott tárgyaljuk részletesebben, de az imperatív nyelvek is használhatják); Halmaz és batyu típus (ez sem az imperatív nyelvek jellemző típusa. A Modula 2 nyelv pl. ismeri.); Rekord, struktúra, vagy union típus. A programozó típus-definiálása során definiálni kell mind a reprezentációt, mind az operációkészletet. Az előbbiből adódik majd a helyfoglalási hossz és az értékkészlet, utóbbiból az operációkészlet. Az imperatív nyelvek fejlesztői mind a reprezentációk, mind az operáció-készlet definiálásához adni szoktak szabályokat, lehetőségeket és korlátokat, az objektum orientált programozásban azonban a programozó típus (osztály) definiálási lehetőségei kiszélesednek. Az új típusok definiálása után a definiált új típus ugyanazt a státust élvezheti, mind a régebbi típusok, legalább is a korlátlanul ortogonális nyelvek esetén. Az ortogonalitás általánosabban azt jelenti, hogy néhány fontos alapelvet betartva építkezünk, ezeket az alapelveket következetesen betartva. Kicsit pontosítva itt azt jelenti, hogy bármely típus-kostruktornál alkalmazhatunk bármely már korábban definiált típust, vagy másképpen: egy alapelv használatát a többi elv megléte vagy hiánya nem befolyásolja. A típusok világában kombinációs ortogonalitást jelent az, hogy akármilyen összetett deklarációban akármilyen ismert deklarációs mechanizmust használhatunk. A C-ben ez néha sérül (pl. union deklarációban inicializálás tilos), az ADA ebben jobb. A fajta ortogonalitás – ha egy összetett típus tagja lehet alap típus, akkor akármilyen típus is lehet – rendszerint biztosított a legfontosabb nyelvekben (C-ben is, ADA-ban is). A számbeli ortogonalitással – ahol egy deklaráció használható, ott zéró vagy tetszőleges számú deklaráció is használható -- is lehetnek gondok, legalább is az, hogy a zéró változat különleges jelölést kívánhat.

2

Nem lehet hangsúlyozni, milyen fontos dolog a programok olvashatósága! Gondoljuk meg, egy forrásprogram részt mennyivel többször olvasunk, mint írunk!

12


Az ortogonalitás tisztává teszi a nyelvet. Az egyszerű alapelvek követése feleslegessé tesz elkerülhető kérdéseket, segítheti a fordítóprogramok fejlesztőit. A ortogonalitás szép példáját mutatják a C nyelv összetett deklarációi, azok típuskonstruktorai, és a típus-kostruktorok valamint a nekik megfelelő operátorok viselkedési szabályai. Tanulmányozzák a C komplex deklarációs lehetőségeit [Darnell, Margolis, 1988]! Még mindig a típusok világánál maradva, szólhatunk a korlátozott típusokra való igényről. Hibalehetőségek elkerülését segíthetik a korlátozások. Egy egyszerű példán szeretném bemutatni a problémát. A hőmérsékletek Celsius fok mérőszámait tartalmazó változók típusának természetesnek tűnően megfelelnek valamilyen szélességű és pontosságú lebegőpontos típusok. Az értékkészletük elegendő (sőt, túl nagy is lehet). Az operációkészletükkel van azonban gond: hőmérsékletekkel kapcsolatban összeadások, különbségképzések, többszörözések, hányados képzések és összehasonlítások természetesen adódhatnak, hatványozásnak azonban nincs értelme. A lebegőpontos alaptípusokat viszont lehet hatványozni. Lehet, hogy erőltetett a példa, de érzékelteti, hogy néha szükség lehet korlátozott típusokra. Egyes nyelvek -- lehet, hogy közvetve -- biztosítanak korlátozott típusokat. Tömbindexeknek lehetnek pl. ilyenek. Volt már szó a típusegyezőségről a típusnevek újranevezése során. A kérdés úgy merül fel, hogy vajon mikor tekinthetünk két típust egyezőnek, esetleg hasonlítónak. Strukturális típusegyezőségről beszélünk, ha a két típus értékkészlete és operációkészlete megegyezik, és név egyezőségnek, ha a típusnevek egyeznek. Az utóbbi a szigorúbb egyezőség, és csakis névvel ellátott típusoknál van értelme. A strukturális egyezőség, nem egyezőség meglehetősen gyakori probléma, ui. összetett típusú változókat gyakran hozunk létre, anélkül, hogy az összetett típusnak kifejezetten nevet adnánk! A C nyelvben pl. névegyezőséget kívánnak bizonyos struktúra- és union operációk (értékadás), strukturális egyezőség kellhet csupán minden máshoz. Sőt, automatikus típus-átalakítás valósulhat meg a strukturális egyezőség hiányában bizonyos szituációkban. A típuskonverzió problémája akkor léphet fel, ha egy helyzetben valamilyen típust várunk, és ott mégis, más típusú adat van. Vajon történjen ekkor automatikus típus-átalakítás, vagy sem? Melyik a jobb megoldás? A C-ben az integrális típusok „szélesítő” konverziója egészen természetes. Az int-to-float átalakítás is természetes, fordítva azonban információvesztés lenne. A típus előrevetés kifejezett alkalmazása programozói fegyelmet kíván, némely esetben elkerülhetetlen. Az ADA ebben szigorúbb, erősen tipizált, erős típus-ellenőrzéses nyelv.

4.2.3. A programvezérlési szerkezetek kérdésköre Az imperatív paradigma szerint a programozó teljes kontrollja alatt van a végrehajtás menete. A programozó alapvetően három, bizonyos nézetek szerint négy vezérlési szerkezetet használhat a programvégrehajtás menetének szabályozására. Az alapvető szerkezetek a Soros végrehajtási szerkezetek (szekvenciális programszerkezet);


13

A különböző választási, elágazási szerkezetek; A különböző ismétlési szerkezetek, más neveken hurkok, ciklusok. Egy bizonyos felfogásban a végrehajtás menetét szabályozó szerkezetek a rutinhívások is. Kétségtelen, hogy a legegyszerűbb programszerkezetek a soros szerkezetek. Gyakoriak is. Egymás után végrehajtandó utasítások képezik ezeket a szerkezeteket. A soros végrehajtáshoz az egymás utáni utasításokat mutathatja egy sorszám (sequencer). Kifejezett sorszámok (explicite sequencer) lehetnek az utasításcímkék, mint amilyeneket egyes Basic nyelvjárások használnak. Kifejezett sorszámok nélküli nyelvek esetén az utasításokat utasítás határolók választják el, határolják, és egy utasítás végrehajtás után a határoló utáni, azaz a következő utasítás végrehajtása következik. Az utasítások lehetnek egyszerű vagy összetett utasítások. Utóbbiaknál az ismeretes az utasítás teste (body) fogalom. A legtöbb nyelvben a kombinációs ortogonalitás koncepciója miatt az összetett utasítás pontosan úgy kezelhető, mint az egyszerű. A modern nyelvek a fajta ortogonalitási követelménynek – ha egy helyen lehet valamilyen utasítás, akkor ott akármilyen lehet – megfelelnek. A számbeli ortogonalitási követelményt – ahol lehet utasítás, ott akárhány lehet -már nehezebb teljesíteni. Az egynél több előfordulás gondot okozhat egyes összetett utasítás testének meghatározásához, ezt a problémát összetett utasítás határolókkal (begin, end, vagy {, } szimbólumokkal) képzett utasítás blokk képzésével szokták megoldani. A nulla előfordulás lehetőségét – ez is követelmény a számbeli ortogonalitáshoz – az üres utasítás (void|null statement) koncepcióval oldják meg. A szekvenciális szerkezetek mellett a választások, elágazások is alapvető programszerkezetek. Az elágazási lehetőségeket általában két összetett utasítással biztosítják a nyelvek: az if utasítással, illetve a switch vagy case utasítással. Az if két vezérlési fonál közötti választást biztosít egy feltétel teljesülésétől függően. A fajta ortogonalitás miatt persze a két ág további if-ekkel tovább is elágaztatható. Az egyes nyelvekben switch, másokban case utasítás egy kifejezés kiértékeléséből kapott pillanatnyi érték illeszkedésétől függően eleve több vezérlési fonál közül válasz egyet. Végül a ciklusok szervezésére is szüksége lévén a programozóknak, a programozási nyelvek tartalmaznak ciklus utasításokat. Lehet ismételni egy utasítást – akár összetettet is -- előre kalkulált számszor (for). Rendszerint egy ún. ciklusváltozó számlálja a lefutásokat, minden futamban változtatva az értékét (akár újraszámolva az értékét, akár egy listából véve a soron következő elemet). De lehet ismételni egy utasítást amíg egy feltétel fennáll (while), vagy amíg az bekövetkezik (until). Ismerjük ezek „elől tesztelő” és „hátul tesztelő” változatait. Az összetett ciklus utasítás teste lehet utasítás blokk. Ebben szerepelhet a break és a continue utasítás is. A break „kiugrik” a ciklusból, és a ciklus utasítás utáni utasításra adja a vezérlést. A continue pedig megszakítja a blokk végrehajtását és azonnal a következő ciklusmenet végrehajtására tér (a ciklusszámláló igazí-

14


tásával és elől tesztelő ciklusnál a teszteléssel persze). A break és continue utasításokat – szemben a goto utasítással, a szakemberek nem kárhoztatják. A rutinhívások kérdéskörét egyesek – akik az imperatív paradigma elveiből a vezérlés menetének lépésenkénti meghatározását tartják fontosabbnak -- szintén a programvezérlés menetének befolyásolására való szerkezetnek tekintik. Kétségtelen igazolható ez a felfogás, hiszen a rutinhívás helyéről a programvezérlés menete ugrik a rutin belépési pontjára (természetesen az argumentumátadás megtörténik, de e felfogás támogatóinak nem ez a fontos), majd a rutinból visszatérve a vezérlés a hívás utáni utasítással folytatódik (s függvények visszatérési értéket is adnak vissza, ami e felfogás szerint nem lényeges). Mindazon nyelvek, melyekben eljárás (procedure) típusú rutinozási lehetőség van, többé-kevésbé követik ezt a felfogást. Más nyelvek fejlesztői csakis a függvény típusú rutinokat engedik. A függvénynek mindig van visszatérési értéke, ami „megjelenik” ott, ahol a függvényhívás történik, és ezzel egy kifejezés operandusa lehet. Felfogásbeli különbség ugyanabban a paradigmában: ha az adatokon és típusokon van a nagyobb hangsúly, akkor a rutinok használata értékkiszámítás, azaz kifejezés, ha viszont a lépésenkénti végrehajtás a hangsúlyos, akkor a rutinozás a vezérlés menetének egyik meghatározási módja. A Neumann típusú gépek hiba- és esemény-kezelése jellegzetes. Miután az imperatív nyelvek nagyon illenek a Neumann gépekhez, ezek eseménykezelése tükrözi a gép hibakezelését. Esemény bekövetkezése a Neumann gép számára jelződik. A jelzés hatására gépi instrukció-folyam végrehajtása megszakad (interrupt), a gép állapota lementődik, majd a vezérlés az esemény kezelőjére (handler) ugrik. Ha a kezelő instrukciófolyamból van visszatérés, a gép állapotot visszaállítják, és folytatódik a „normál instrukciófolyam futása. Az eseménykezelést programozási nyelvek támogathatják, bizonyos feltételek bekövetkezéshez (on condition) kezelő rutinokat (handler) rendelve. A program futásában az esemény bekövetkezése váratlan, és sok esemény aszinkron, abban a tekintetben, hogy nem lehet utasításokhoz kötni a bekövetkezését. Az aszinkron jelleg miatt elágazó utasításokkal nem lehet a feltétel bekövetkeztét ellenőrizni. A korszerű eseményvezérelt (event driven) programozáshoz a nyelvi fejlesztők szoktak on condition mechanizmusokat biztosítani.

4.2.4. Állapotátmenetek az imperatív programokban Az imperatív programok változóinak pillanatnyi értékei adják a program futási állapotát. (Az állapottér elemeihez tartoznak persze a processzor regiszterei, az I/O eszközök pufferei és regiszterei is.) Egy-egy értékadás változtatás ezen az állapottéren. Az előbbiekben már ismertetett felfogásbeli különbség – az adatok vagy a lépésenkénti végrehajtás a hangsúlyosabb -megjelenhet az értékadással, ezzel az állapotváltoztatással kapcsolatban is. Azon nyelvekben, ahol a fejlesztők a vezérlés mentének megszabását tartják fontosabbnak, van értékadó utasítás. Az értékadó utasítás jobboldalán kiértékelendő kifejezés szerepel, a kifejezés az utasításnak része. Jellemzően ilyen nyelv a Pascal


15

vagy az ADA. Az adatokra é s típusaikra koncentráló fejlesztők nyelveiben a kifejezések állnak előtérben. Minden program elem tulajdonképpen kiértékelendő kifejezés, emlékszünk, a függvények is arra valók, hogy egy értéket adjanak. Nincs kifejezett értékadó utasítás e felfogás szerint, hanem értékadó kifejezés van, mint a C nyelvben. És miután a nyelv szabályai szerint az utasításhatároló szimbólum elhelyezése egy kifejezés után kifejezés utasítássá teszi azt a kifejezést, az értékadó kifejezés mellékhatásaként (side effect) történik az értékadás. Az imperatív programoknak meglehetősen nagy állapottere van, a program futása tekinthető az állapotátmenetek láncolatának.

4.2.5. Az imperatív programok számítási modellje Adott programozási paradigmának megfelelő programozási nyelvek számítási modelljei ugyanazok. A számítási modell összetevőit [Sima et al, 1998] szerint a számítások alapelemei, a problémaleíró modell és a végrehajtás modellje képezik. A problémaleírás modelljét a leírás jellege és módszere határozza meg. A végrehajtás modelljét a végrehajtási szemantika és a végrehajtás kontrollja adja. Az imperatív nyelvekben a számítások alapelemei az azonosítható entitásokhoz rendelt típusos adatok, a literálok és változók. A problémaleírás imperatív jellegű, utasítási lépéseket megadó. Egy felfogásban procedurálisnak is jellemzik a problémaleírást, ekkor kompozíciósdekompozícós problémadefiníció hangsúlyozódik. A végrehajtási modell egyik összetevője (a végrehajtási szemantika) állapot átmeneti szemantika, a másik összetevő (végrehajtási kontroll) közvetlen kontroll.

4.3. A FUNKCIONÁLIS PROGRAMOZÁS PARADIGMÁJA Az imperatív nyelvek segítik a programozót, hogy algoritmusokat rögzítsen, amik pontosan megadják, milyen lépésekben oldjuk meg a problémát. A hozzátartozó számítógépi modell állapotokat kezel a változókon át, ahol is az állapotok a gép memória tartalmának változatai. Az imperatív paradigma és a Neumann gép jól megfelel egymásnak, és hatékony megvalósítást biztosítanak. A hatékonyság mellet azonban a paradigma néha korlátoz: vannak problémák, melyek nem illenek a Neumann modellhez, az imperatív programozással viszont a problémát a gépi modellhez akarjuk illeszteni. Ez kötöttség, jó lenne néha ettől megszabadulni. Egyes problémák esetén azzal foglalkoznánk, hogy mit kell kiszámítani, ahelyett, hogy azt keresnénk, hogyan, milyen lépésekben, hogyan kell kiszámítani az eredményt.

4.3.1. A paradigma A funkcionális program a nyelvhez előre definiált és a programozó által definiált függvények hívásából áll.

16


A függvények kifejezéseket értékelnek ki. Egy függvény – mint a matematikában – egy értéktartományból képez le egy másik értéktartományba. A függvény ugyanazokkal az argumentumokkal ugyanazt az eredményt adja, nincsenek hát állapotok és mellékhatások, csakis értékkiszámítás van. Nem számít, hogy mikor hívjuk a függvényt, csak az, hogy melyiket hívjuk. Nincs tehát értékadás, hanem csak érték kiszámítás. A funkcionális programban a függvényeket természetesen definiálni kell. A program tehát függvénydefiníciók és függvényhívások sorozata. Természetesen, a funkcionális programok is használnak adatokat. Ezek tulajdonképpen típusos értékek és ezek listái (ismerünk típus nélküli adatokat kezelő nyelvet is). Név szerint két ismert funkcionális nyelvet említek meg. Egyik nyelv a Miranda3. Ez tiszta funkcionális nyelv. A másik, a LISP4. A LISP a legrégebbi funkcionális nyelv, valójában nem tisztán funkcionális jellegű, mert van benne értékadás és ezzel nem teljesen állapotmentes.

4.3.2. A funkciók A nyelv alapvető építőkövei a funkciók. Minden függvénynek van neve és zéró vagy több argumentuma. Egy függvény kiszámít egy értéket – ami lehet összetett, állhat több elemből – pusztán az argumentumaitól függően. Azaz ugyanazzal az argumentumokkal a függvény mindig ugyanazt az értéket szolgáltatja. A függvény argumentumai értékek – lehetnek összetettek --, amiket névvel ellátott, vagy névnélküli adatok, kifejezések, vagy éppen függvények biztosítanak. A rekurzió abszolút természetes a funkcionális nyelvekben, ismétlések és ciklusok helyett éppen a rekurziót használhatjuk. Nézzünk egy egyszerű példákat mind a Miranda, mind a LISP nyelvben (4.6. ábra). Figyeljünk fel arra, hogy a feltételes kifejezésekkel definiált érték-kiszámítás (a faktoriális függvény definíciókban látunk ezekre példát) egymás után írt programszerkezetei nem egymás után végrehajtható lépéseket jelentenek, bár a sorrendjük természetesen nem cserélhető fel!

3 4

Részletesebben lásd: [Clack et al, 1994] Lásd [Zimányi et al, 1989]


Miranda celsius:: num -> num celsius f = (f-32) * 5/9 celsius 68 => 68

17

// típus deklaráció // definíció // hivatkozás

LISP (defun celsius (f) (* (- f 32.0) (/ 5.0 9.0))) (celsius 68.0) => 68.0 Faktoriális, Miranda fac:: num -> num // típus deklaráció fac x = 1, if x = 0 fac x = x * fac (x – 1), othervise //definíció fac 3 => 6 // hívása Faktoriális LISP (defun fac (x) (if (= x 1) 1 (* x (fac (- x 1))) )) (fac 3) => 6

// definíció // hívása

4.6. ábra Egyszerű mintaprogramok

4.3.3. Adatszerkezetek A funkcionális nyelvek alapvető összetett adatszerkezetei a listák. A lista szerkezet zéró vagy több elemből áll. Az elem lehet -- típusos nyelvnél típusos, nem tipizáló nyelvnél típus nélküli – érték, vagy lista is. A zéró elemből álló lista az üres lista. A lista adatszerkezetben a lista feje (head) a lista első eleme. A lista feje skalár érték, ha a lista első elem maga skalár, viszont lista, ha az lista. A lista farka (tail) is definiálható: a lista fejé nélküli maradék lista a lista farka. A lista farka mindenképpen lista. Érezzük a rekurzió koncepciót a lista fogalomban, annak definíciójában. Igen, a lista rekurzíven definiálható: A lista vagy üres lista, vagy fejből és farokból áll. A lista feje vagy érték, vagy maga is lista. A fej az első eleme a listának. A lista farka mindig lista, a fej nélküli maradéka a listának. A 4.7. ábrán néhány példát mutatunk be lista szerkezetekre.

18


Miranda listák [1, 4, 9, 6] [1 .. 10] [’a’, ’b’, ’c’] [] [[2, 4, 6], [1, 3, 5, 7, 9]]

// 4 egész listája // 10 egész listája // 3 karakter listája // az üres lista // 2 listából álló lista

LISP listák (1 4 9 6) ("a" "b" "c") () nil

// 4 egész listája // 3 karakter listája // az üres lista // az üres lista

4.7.ábra Példák listákra

4.3.4. Beépített függvények Néhány fontos beépített függvényt megemlítünk, először a Miranda nyelvi nevét, majd a LISP nevet, törtvonallal elválasztva: A lista fejét előállító függvény a hd/CAR. A lista farkát a tl/CDR adja. Beszúrás a lista elejére a :/CONS függvénnyel történhet. Listákat összefűz (concatenate) a ++/APPEND operátor, illetve függvény. Elemekből listát képez a pair/LIST függvény. Egy lista hosszát adja vissza a #/length függvény. Az aritmetikai operációk a Mirandában akár függvénnyel akár operátorokkal összekötött kifejezéssel megadhatók, míg a LISP függvényeket alkalmaz itt is. Viszont az aritmetikai függvények neve lehet a mi általunk szokásosa operátorként használt karakter. A 4.8. ábrán egyszerű példákat mutatunk be beépített függvényhívásokról, operátor használatról Miranda nyelven. A funkcionális nyelvek használják a magasabb rendű függvények koncepcióját. A magasabb rendű függvény egy argumentuma maga függvény. A magasabb rendű függvény argumentuma nemcsak egyszerűen értéket szolgáltat, hanem ezt az argumentum függvényt „használjuk” a többi argumentumra. Egy tipikus példa a map magasabb rendű függvény, melynek első argumentuma egy függvény, másik argumentuma lista, maga a függvény pedig listát eredményez. Az első argumentumot alkalmazza minden listaelemre, így állítja elő az eredmény listát. Másik tipikus magasabb rendű függvény a foldr (fold right, „göngyöld” jobbra)


19

függvény. A 4.9. ábrán mintákat mutatunk be a map és foldr függvények használatára. Miranda hd [10, 20, 30] tl [10, 20, 30] 5: [] 3 : [5, 4, 6]

=> => => =>

10 [ 20, 30] [5] // beszúrás [3, 4, 5, 6] //beszúrás

A beszúrás típus-deklarációja: : :: (α, [α]) -> [α] // ahol α bármilyen típus A hossz-visszaadás # függvénye kb. így lehet definiálva: # :: [α] -> num // típus-deklaráció # x = 0, if x = [ ] # x = 1 + # (tl x), otherwise // definíció # [3 .. 5] => 5 // hívása A lista összefűzésre van ugyan operátor, mi egy függvényt definiálunk erre példaként: concat :: [α] [α] -> [α] concat x y = y, if x = [ ] concat x y = (hd x) : concat (tl x), otherwise

4.8.ábra Miranda példák

4.3.5. A kiértékelési sorrendről Előzőleg, a függvénydefiníciókban használatos feltételes kifejezések említésekor mondtuk, hogy bár programsorok sorrendje nem cserélhető fel tetszőlegesen, az egymásutániság nem jelenti az egymás utáni számítási lépések definícióját. Nem jelenti azt, hogy „tedd előbb ezt, utána ezt…”, mint az imperatív nyelvi utasítások. A kiértékelési sorrend mégis érdekes lehet. Már az imperatív nyelvek operátorainak precedencia- és asszociativitási (tapadási) szabályai felvetik ezt a problémát, és ha megjegyezzük, hogy ez nem az imperatív nyelvek programvezérlési menetet meghatározó sorrendiségi probléma, akkor megérthetjük és elfogadhatjuk, hogy a funkcionális paradigmában is jelentkezik ez a probléma. A feltételes kifejezések elemzésével eljuthatunk arra a következtetésre, hogy nyilvánvalóan előbb a feltétel értékelődik ki, és utána a feltételnek megfelelő kifejezés. Mi a helyzet azonban függvények argumentumaival? Azok mind kiértékelődnek? Milyen sorrendben?

20


Miranda map func lista // a map hívási szintaxisa Legyen egy triple (háromszorozó) függvényünk triple :: num -> num triple x = x * 3 … és ekkor … map triple [1,2,3, 4] => [3, 6, 9, 12] Párok elemeinek összegéből álló lista az eredmény map (+) [[1, 2], [3, 4]] => [3, 7] A foldr hívási szintaxisa foldr func x lista … és ekkor … foldr (+) 0 [2, 4, 6] => (2+(4+(6+0))) => 12 // sum foldr (*) 1 [2, 4, 6] => 48 // produktum foldr (&) true lista // logikai és minden listaelemre 4.9 ábra Magasabb rendű függvényekre példa Egyes függvények minden argumentuma kiértékelődik. Ezek az eval típusú5 függvények. Mohó kiértékelésnek (eager evaluation) nevezzük ezt az esetet. Vannak függvények, melyeknek nem minden algoritmusuk értékelődik ki, ezek a nem eval típusúak. Az argumentumok kiértékelési sorrendje kétféle lehet. Egyik sorrend az ún. applikatív sorrend (applicative order), mikor is a legbelsőbb kiértékelendőből kiindulva történik a kiértékelés. A mások sorrend neve a normál sorrend (normal order). Ekkor a legkülsőbb kiértékelendőket kezelik először. Miranda cond :: cond b cond b fact1 :: fact1 n

bool α α -> α x y = x, if b x y = y, otherwise // applikatív renddel num -> num = cond (n = 0) 1 (n * fact1 (n – 1))

cond felt a b fact1 3 => error

// (1) hívás // (2) hívás

4.10. ábra Gondok az applikatív kiértékelési rendnél Matematikai képzettségünk miatt is, az applikatív sorrend tűnhet természetesebbnek. Nos, a mohó kiértékeléshez az applikatív sorrend tartozik, míg a halasztott kiértékeléshez (lazy evaulation) a normál sorrend. 5

Az angol evaluate szó rövidítéséből.


21

A lusta kiértékelés és a hozzá tartozó normál rend szükségességét a 4.10. ábra példáján mutatjuk be. A mohó kiértékelésű és applikatív rendben kiértékelődő cond függvényünk mindhárom argumentuma kiértékelődik, a szükségességétől függetlenül, Ez az ábra (1) számú hívásánál hibát még nem feltétlenül okoz, de veszteséget mindenképp, hiszen az a és b argumentumból elég lenne az egyik kiértékelése. A példában azonban a cond függvényünket használjuk egy fact1 nevű, itt definiált faktoriális számításra. Nos, a mohó kiértékelésű cond itt hibát okoz, a harmadik argumentum mohó kiértékelése miatt nem tud terminálódni a hívás. Ez az igény vezetett a halasztott kiértékelés koncepcióhoz. A halasztott kiértékelésben nem minden argumentum értékelődik, akár azért, mert kifejezetten letiltjuk, akár azért, mert nincs rá szükség. Mind a Miranda, mind a LISP ismeri a halasztott kiértékelés koncepciót. A halasztott kiértékelés még egy előnye jelentkezik a Mirandában: ez vezetett a koncepcionálisan végtelen adatszerkezetekhez. Egyszerű példákon nézzük a végtelen adatszerkezeteket (4.11.ábra.). Miranda [1 ..] hd [1 ..] hd (tl [1 ..])

// végtelen lista => 1 // helyes hivatkozás => 2 // helyes hivatkozás

# [1 ..]

=> error

// a lenght hibás

4.11.ábra Példa végtelen listára

4.3.6. A funkcionális programozás számítási modellje Emlékeztetünk, hogy a számítások alapelemei, a problémaleírás modellje és a végrehajtás modellje határozzák meg együttesen a számítási modellt. A funkcionális programok számítási alapelemei a típusos, vagy típus nélküli értékek, és ezek listái. A listák összetett adatszerkezetek, melyek rekurzíven definiálhatók. A problémaleírás modellje deklaratív. Függvényeket adunk meg és ezekre hivatkozunk. A deklaratív jellegből adódóan a függvények megadásának sorrendje nem a kiértékelésük sorrendjét adja, nem „lépéseket” jelent. A programokban a függvény definíciók sorrendje a láthatóságukat, érvényességüket befolyásolhatja csak. Természetes koncepció a rekurzió. A végrehajtási szemantika applikatív. Alkalmazzuk a definiált függvényeket. A végrehajtási kontroll ezért igény szerinti. A funkcionális paradigmának megfelelő programok állapotmentesek. Ugyanazokkal az adatokkal mindig ugyanazt az eredményt adják. Pont az állapotmentesség koncepció miatt az I/O lehetőségeket meglehetősen nehéz implementálni a funkcionális nyelvekhez.

22


Két funkcionális nyelvvel valóismerkedést ajánlunk az olvasónak. Egyik a Miranda. Ez a paradigmának minden mértékben megfelelő nyel, tanulmányozható a [Clack et al, 1994] irodalomban. A másik nyelv a LISP nyelv. A LISP sért néhány funkcionális programozási elvet. Vannak benne „álfüggvények”, olyan függvények, melyeknek van mellékhatása. Van benne értékadás és lehetnek globális változók benne, ezzel van állapot és állapot változás a LISP programokban. A LISP alapfogalmakat, a LISP programozást megtanulhatjuk a [Zimányi et al, 1989] irodalomban.

4.4. A LOGIKAI PROGRAMOZÁS Az eddig tárgyalt paradigmák a számítógép orientáltságtól a probléma orientáltság felé haladtak. Az imperatív programokban a programozó utasítja a gépet, hogyan, milyen lépésekben oldja meg a problémát. A funkcionális nyelvekben a fókusz a problémára tevődik, nem a tevékenységre. Tovább lépünk itt, a logikai programozás paradigmájával. Egy logikai program tények és a probléma sajátosságainak felsorolása, és a logikai programozási rendszer feladata, hogy a megoldást kikövetkeztesse. A logikai programozás alapja a Horn logikának nevezett formalizmus. A tanulmányozásra javasolt logikai programozási nyel a Prolog6 is a Horn logikára épül. A Horn logika legfontosabb logikai kifejezése a Horn-klóz (Horn clausa). Egy Horn-klóz azt fejezi ki, hogy egy állítás igaz, ha zéró vagy több más feltétel igaz. Például a következő mondatot fejezheti ki: Ha valaki öreg és bölcs, akkor ő boldog. Angolul: If a person is old and wise, then that person is happy. Zéró vagy több feltétel lehet a Horn-klóz if részében és egy következmény a then részében. A feltétel nélküli klóz tényt (fact) jelent. A feltétellel rendelkező klóz szabály.

4.4.1. A paradigma Ezek után megkísérelhetjük megfogalmazni a logikai programozás lényegét. A logikai programokban a programozó felsorol (deklaratív módon megad) szabályokat és tényeket. Megad ezek után egy eldöntendő kérdést, és a programozási rendszer következtető motorja (inference enginee) automatikusan kikövetkezteti a szabályok és tények feldolgozásával, hogy az igaz-e vagy sem. Kérdezhető a rendszertől, hogy valamilyen feltevés igaz-e vagy sem, illetve, hogy létezik-e valami, ami adott feltételnek megfelel. Ha a feltevés igaz, akkor azt mondjuk rá, hogy bizonyított (proved). A Horn-klózok a következő módon formalizálhatók: G0 <- G1, G2, …, Gn. Ennek a jelentése a következő: ha a G1-től a Gn-ig formalizált feltételek mind igazak, bizonyítottak, akkor a G0 is igaz, bizonyított. 6

Lásd [Prolog] és [Flach,2000]


23

A formalizált Horn-klóz baloldali része a szabály feje (head), a baloldali rész a törzse (body). A G0-től a Gn-ig a szabály elemek a célok (goals), a testben található célokat szoktuk alcéloknak (subgoals) is nevezni. A vessző elválasztót a szabály testében (az alcélok között) logikai és operációnak olvashatjuk. A fejet és törzset elválasztó <- szimbólum értelme a ha (if), vagy akkor kifejezés, nem pedig az „akkor és csakis akkor”. Ez azt is jelenti, hogy ugyanarra a G0 célra több szabály is lehet. Speciális eset az, amikor a test, a baloldali rész elmarad, az n=0. Ekkor a G0 mindig igaz, azaz az ilyen szabály a tény (fact). A célokban predikátumok lehetnek. Egy-egy predikátum a nevéből és zéró vagy több argumentumából állva formalizálható. Pl.: öreg(Confucius). Itt a predikátum név az öreg, az argumentum a filozófus neve. A predikátum jelentése az a tény, hogy Confucius öreg. Ez egy tény itt. Az argumentumok változók és konstansok lehetnek. A fenti esetben a Confucius konstans. De írhatjuk ezt is: öreg(X). Itt az X argumentum változó.

4.4.2. Az első példa A 4. 12. ábrán bemutatunk egy nagyon egyszerű logikai programot. öreg(Confucius) // 1. tény bölcs(Confucius) // 2. tény boldog(X) <- öreg(X), bölcs(X) // 3. szabály ?- boldog(Pisti)

// 4. kérdés

?- boldog(X)

// 5. kérdés

4.12. ábra Egyszerű logikai program Maga a program három sorból áll, két tényállításból és egy szabályból. Azt hiszem, jól olvasható: Confucius már öreg, mondja az 1. tény, ugyanakkor bölcs is (2. tény). A tényeknél a <- szimbólum elmarad. A 3. sor szabálya azt mondja, ha valaki öreg és bölcs, akkor boldog is. A 3. szabályban az X változó itt univerzálisan kvantifikált („minden X-re igaz, hogy …”) A program megírása után feltehetjük a kérdést (4. sor): vajon Pisti boldog-e. A ?- szimbólum konvencionálisan a kérdés (query, initial goal) előtt áll. A kérdés maga egy cél. A rendszer ezek után válaszolni fog, hogy a kezdeti célt igazolni tudja-e a (A fenti program esetén nem.) A kérdést feltehetjük az 5. sorbeli formában is. Itt az X változó egzisztenciálisan kvantifikált („létezik-e X, aki…”). A rendszer ekkor is válaszolni fog, hogy igen, vagy sem. A helyzet az, hogy ha a válasza az igen, nem feltétlenül tudjuk meg, hogy ki az, aki boldog.

4.4.3. A szabályok kiértékelési sorrendjéről Tegyük fel, hogy programoztuk a 4.13. ábrán látható szabályokat az ott látható sorrendben, és végül feltettük a 7. sorszámú kérdést: vajon Tóni boldog-e.

24


boldog(X) <- gazdag(X), híres(X) boldog(X) <- fiatal(X), szerelmes(X) híres(X) <- popsztár(X) híres(X) <- mozi-sztár(X) mozi-sztár(Tóni) gazdag(Tóni)

// 1. // 2. // 3. // 4. // 5. // 6.

?- boldog(Tóni)

// 7.

4.13. ábra Egy logikai program A kérdésre két szabály is válaszolhatna, az 1. és a 2. számú. Tegyük fel, hogy a leírásuk sorrendjében próbálkozik a bizonyítással a rendszer. Ekkor az 1. számú kérdést kezdi előbb vizsgálni, X változóhoz a Tóni értéket kötve (binding), megkísérli azt bizonyítani. Ehhez igazolnia kellene, hogy a gazdag(Tóni) és híres(Tóni) igaz. Végignézve a szabályokat az elsőre talál tényt, a 6. sorszámút. A másodikat is bizonyítani akarja, és talál két szabályt – a 3-ikat és 4-iket – a hírességre. Próbálkozik a 3. számúval, azt nem tudja igazolni. Ekkor próbálkozik a 4. számúval, nos, ahhoz megtalálja az 5. számú tényt. Igazolt tehát a 4. szabály, ebből következően az 1.szabály törzsének második predikátum, azaz az 1. szabály, azaz a végső válasz az igen. Vajon jó a fentiek szerint keresési sorrend? Sorrendbeli kérdés két helyzetben is fennáll: mi legyen a sorrend, ha alternatív szabályok vannak, és mi legyen egy szabály törzse predikátumainak kiértékelési sorrendje. Nos akármi is a sorrend7, ha egy alcél bizonyítása nem sikerül (zsákutcába jutott a következtetési láncolat), akkor meg kell próbálni egy másikat. Visszalépésnek (back tracking) nevezzük ezt a mozzanatot. Zsákutcába jutva mindig eggyel lépünk vissza, szükség esetén értékeknek változókhoz való kötését feloldva, új kötéseket megvalósítva. Az eggyel való visszalépés biztosítja, hogy a keresési teret teljesen bejárjuk: ha van megoldás, azt biztosan megtaláljuk. A változókról jegyezzünk meg még annyit, hogy kezdetben azok nem kötöttek (unbound). Ha egy változó „értéket kap”, akkor az kötötté (bound) válik: az érték kötődik hozzá. Ekkor már értékét nem változtathatja, kivéve, ha visszalépés következett be és új kötésre van szükség. Jegyezzük meg, hogy a végső nem válasz azt jelenti, hogy a kezdeti cél nem következtethető ki a szabályokból és tényekből.

7

Mélységben először keresési sorrendnek nevezik a a klózok alternatíváit a leírási sorrendben, a törzs alcéljait balról jobbra sorendben való keresést. Egyes rendszerekben vannak keresési sorrend vezérlési parancsok.


25

4.4.4. A logikai programozási nyelvek számítási modellje A logikai nyelvekben a számítási alapelemek a – többnyire -- Horn-klózokkal formalizált tények és szabályok, a szabályok predikátumai és ezek argumentumai. A szabályok predikátumainak argumentumai változatos formájúak lehetnek. Tipizált és típus nélküli adatkezelés is lehetséges. A predikátumok változóinak értékadása az ún. kötéssel történik. A probléma leíró modellt logikai formulák adják. A leírás deklaratív jellegű: a programozó felsorolja a tényeket és szabályokat, elvileg ezek sorrendje csak a hatékonyságot befolyásolja. A végrehajtási szemantikát egy következtető gép határozza meg. A következtető gép igazolhat egy-egy kérdést, a szabályok és tények közötti kereséssel, alcélok igazolásával. A végre hajtás kontrollja lehet mélységben vagy szélességben való keresés, a következtetési lánc elakadása esetén visszalépéssel (hogy a teljes keresési teret bejárjuk). Logikai programozást elsősorban a mesterséges intelligencia problémák megoldásánál alkalmaznak. Nagy tere van a logikai programozásnak a szakértői rendszerek területén is.

4.5. AZ OBJEKTUM ORIENTÁLT PROGRAMOZÁS Foglaljuk össze az eddigi paradigmák fő jellemvonásait. Az imperatív paradigma a hogyan kérdésre válaszolt. Mely adatokkal milyen lépésekben oldja meg a gép a problémát. A funkcionális programokban a fókusz a problémára tevődött, mit oldunk meg, ezzel foglalkozunk. A logikai programozásban még inkább a problémára magára figyelünk, nem a megoldási lépésekre. Mint látni fogjuk, az objektum orientált programozásban (Object Oriented Programming, OOP) a hangsúly a „mit” kérdésén van, ezen belül az ún. objektumokon. Megvan azonban benne az imperatív szemléletből a lépésenkénti végrehajtás mozzanata, az osztály koncepció az imperatív (vagy procedurális) nyelvek típus-, az objektumok pedig e nyelvek változó fogalmának a kiterjesztései. A programozási szemléletmódok fejlődése – többek között – két dolgot eredményezett. A fejlődéssel egyre inkább elszakadtak a gépi belső ábrázolási technikáktól (már az imperatív gondolatkörben is megjelent a platform-függetlenség), másrészt a bonyolultság kezelésére különböző absztrakciós technikákat alkalmaztak. A klasszikus absztrakció: az elvonatkoztatás és vele szemben a részletezés, az osztályozás és a vele szembeni példányosítás, a generalizáció és ellentéte, a specializáció, a kompozíció-dekompozíció egyre nagyobb teret nyert. Némely absztrakciós technika az OOP-ben kiteljesedett. Az OOP nem egyszerűen programozási stílus, ennél általánosabb, egy szemléletmód, modellezés és tervezési módszer is. Az OOP lényegének megragadásához néhány kifejezést körül kell járnunk. Ezek a kifejezések az OOP lényegi jellemzőit, alapelveit, legfontosabb módszereit nevezik meg. Ezek a következők:

26

PROGRAMOZÁSI PARADIGMÁK Absztrakció; Az objektum és osztály koncepció; Információrejtés, szabályozott elérés, egységbezárás; Öröklődés, egész és rész kapcsolatok; Többalakúság; Szolgáltatás, módszerek (metódusok), viselkedés, üzenetek, Antropomorfizmus.

4.5.1. Az OOP paradigma Az absztrakció egy koncepció bonyolult rendszerek megértéséhez, analíziséhez, tervezéséhez. Az absztrakció a lényegtelen képességek, tulajdonságok, aspektusok -- biztonságos módon történő – elhagyása, ugyanakkor a lényegesek megragadása. Ezt a koncepciót széles körben alkalmazzuk, nemcsak az OOP technikákban, de itt is nagyon fontos az absztrahálás. Az objektum határokkal rendelkező entitás. Van állapota (state): attribútumainak pillanatnyi értékei, és van viselkedése (behavior): műveleinek összessége. A programozásban a műveletek a módszerek (methods). A módszerek hatnak az állapotot adó értékekre, az adatokra. Másként fogalmazva: az objektum itt metódusok és attribútum adatok együttese. Az osztály hasonló objektumok csoportjának leírása. A hasonló objektumoknak a tulajdonságai és viselkedésük hasonló. Hasonlóak a kapcsolataik is, közös a szemantikájuk, értelmezésük. Az osztály az eljárás orientált nyelvek típus fogalmának egy implementációja. Egyfajta absztrakciós technikából, az osztályozás – példányosítás technika első eleméből származtatható. Az osztály olyan minta, amiből objektum kreálható. Példányosítható belőle az objektum. Objektumoknak van osztálya, az az osztály, amiből azokat példányosították. Használható az osztály objektuma kifejezés is, egy adott osztályból példányosított objektumra. Mint említettük, példányosítással jön létre az objektum. A példányosított objektum azonossággal rendelkezik. Van azért különbség a változónév (mint azonosító) és az objektum azonosító között: a változónévvel csak hatáskörön belül egyértelmű a hivatkozás, az OID objektum azonosító egyértelműen kell azonosítson (nem érdekel most, hogy hogyan). Összefüggések (relationship, logical connection) vannak, ill. lehetnek az objektumok és osztályok között. Egyik fajta kapcsolat az angolul „is a” kapcsolatnak nevezett viszony. Magyarul „ez egy ez” névvel nevezhetnénk (bár elég furcsán hangzik). A teherautó az egy autó. A személygépkocsi egyfajta autó. Ezekkel a példákkal világíthatjuk meg ezt a kapcsolatot. Az „is a” kapcsolat a generalizálás – specializálás absztrakciós eszköz származéka, az autó általánosabb jellemzőkkel rendelkező osztály, a teher- vagy személyautó pedig örökli az autó minden tulajdonságát és további speciális tulajdonságokkal is rendelkezik. A „has a” kapcsolat – magyarul ezt is csak körülírva tudjuk megnevezni – az egész – része viszonyt tudja kifejezni. A motor, a test, a kerék az autó része. Az


27

autónak van teste, motorja, valahány kereke. Az osztály definíciókban ezt nem az öröklődés koncepcióval kezeljük, hanem tagként vesszük fel a „birtokolt” elemeket. A többalakúság (polimorfizmus) lényege az, hogy bizonyos (egyedi primitív) szerkezeteknek ugyanaz a szimbolikus neve, mégis más-más a funkcionalitása. A többalakúság teszi lehetővé, hogy ugyanarra a helyzetre, üzenetre a különböző osztályok a saját módjukon tudjanak válaszolni. Jegyezzük meg: van „módszer polimorfizmus” és „objektum polimorfizmus” is. Előbbit – remélhetőleg -- megértik később, utóbbi lényege az, hogy bár egy objektum a saját osztályának objektuma, az öröklődési hierarchia miatt szerepelhet olyan szituációban, mintha egy ősosztálya objektuma lenne: mintha felmenő osztályának objektuma lenne. Szóljunk röviden arról, hogy az anropomorfizmus mint módszertani segítség nem az OOP sajátja, de vele jobban magyarázhatjuk az OOP rendszert is. Az objektumoknak lehetnek „emberi karakterisztikái”. Az objektumok „ügynökökként” (agent’s role) szerepelhetnek, egy objektum születik, él és végül elpusztul. Adott esetben az objektumoknak komplikált életciklusuk lehet. Egy objektum –akár saját magának, akár más objektumnak -- adhat valamilyen szolgáltatást. A szolgáltatás valamilyen akciók kivitelezése. A metódus, vagy más néven módszer lépésenként végrehajtott algoritmus, válaszként egy üzenetre. Arra az üzenetre, melynek neve a metódusnak megfelel. A viselkedés az az üzenetkészlet, melyre egy objektum tud válaszolni. Az üzenetek az objektumok kommunikációinak egységei, egy-egy szolgáltatás kérései. Egy üzenet egy metódus névből, továbbá a szükséges paraméterekből áll. Az OOP program egymással kommunikáló objektumok halmaza. A program viselkedését az objektumok közötti kommunikáció határozza meg. A kommunikáció üzenetváltásokkal történik, az üzenet implementációja egy objektum egy metódusának meghívása. Az objektum az üzenetre szolgáltatással válaszol: lefut a módszer.

4.5.2. Az objektum Az objektum diszkrét entitás, van állapota és viselkedése. A diszkrét jelző azt jelenti,hogy környezetétől megkülönböztethető, van határa. Lényeges létező, azaz entitás, egyediséggel rendelkezik. Két objektum akkor is különbözik, ha tulajdonságaik egyeznek, Egy objektum csak önmagával egyezik. Tulajdonságainak (attributes) együttese az állapota (state). Változhatnak a tulajdonságainak értékei, azaz változhat az állapota. A viselkedés (behavior), a működése éppen az állapotának a változtatása. A működése külső vagy belső hatásokra történhet. Egy objektum hathat. Az objektum jellegzetességei (features) a lehetséges állapotainak és viselkedési módjainak együttese. A jellegzetességek részletezését és ábrázolásukat, implementációjukat a 4.14. ábrán láthatjuk.

28


Jellegzetességek állapot & viselkedés

Felbontásuk

Ábrázolásuk

attribútumok & műveletek

adatok & módszerek

4.14. ábra Objektumok jellegzetességei Objektum lehet a valós világ konkrét eleme, pl. egy alma, egy szerszámgép, egy ház. Ezek létezésüktől fogva már azonosítottak, de kaphatnak azonosítót valamilyen módon (pl. leltári számot, helyrajzszámot stb.). Objektum lehet elvont fogalom is, pl. egy intézmény, egy folyamat, egy tranzakció. Lehet egy személy is. Mindenképpen kell kapjanak azonosítót az objektumok (Object Identifier, OID). Az azonosító implementációja sokféle lehet (egy cím, név, egy attribútum érték stb.).

4.5.3. Az OOP számítási modell A számítás alapelemei osztályokba sorolt objektumok. Ezek egységet alkotnak, melyekben elválaszthatatlan az adat- és eljárásmodell. A problémaleírás az imperatív és procedurális jellegzetességekkel rendelkezik. Az ún. öröklődés mechanizmus az újrafelhasználhatósági követelmény végsőkig való kiterjesztése. Az egységbezárás nemcsak az állapot és viselkedés együttes megadást jelenti, hanem az információrejtés és szabályozott elérés mechanizmusa is. A végrehajtási szemantika az objektumok keletkezéséből, viselkedéséből, tulajdonságaiknak változásából származtatható. A végrehajtás az üzenetváltásokkal, események generálásával kontrollálható.


29

[Bal&Grune, 1994] H. E. Bal, D. Grune: Programming Language Essentials, Addison-Wesley, 1994 [Erdélyi et al, 1997] Erdélyi szerk.Erdélyi Ferenc et al.: A technológiai menedzsment informatikai eszközei (PHARE TDQM-HU9305.01-1383) Miskolc, 1997. április. [Kuhn, 1970] T. S. Kuhn: The Structure of Scientific Revolution, Chicago IL: University of Chicago Press, 1970. [Szuromi, 1996] Szuromi Zs.: Programozási paradigmák, Kézirat. ME, 1996. [Darnell, Margolis, 1988] P.A. Darnell, P.E. Margolis: Software Engineering in C, Springer-Verlag, 1988. [Sima et al, 1998] Sima D., T. Fountain, Kacsuk P.: Korszerű számítógéparchitektúrák tervezésitér megközelítésben, Szak Kiadó Kft, 1988. [Clack et al, 1994] C. Clack, C. Myers, E. Poon: Programing with Miranda, Prentice Hall, 1994. [Zimányi et al, 1989] Zimányi M., Kálmán l.? Fadgyas T.: A LISP programozási nyelv, Műszaki Könyvkiadó, 1989. [Prolog] A Prolog programozási nyelv, http://hu.wikipedia.org/wiki/Prolog [Flach, 2000] P. Flach: Logika programozás, Panem, 2000

4. PROGRAMOZÁSI PARADIGMÁK, PROGRAMOZÁSI NYELVEK

Recommend Documents