Gyakorlati alapok III.
Az absztrakció mélységei: az osztály fogalma
Honlapomon már sokszor került említésre, miszerint a számítógép voltaképpen az esetek döntő többségében a való világ modellezését, szimulációját végzi el. Nézzük meg az ehhez vezető, néhány évezredes "absztrakciós" utat!
Elöljáróban jegyzem meg, hogy az alábbi eszmefuttatás merőben hipotetikus (mellette igyekszem kissé humorossá tenni), ezért nem kívánok állást foglalni a különböző fejlődés-, és teremtéstörténetek között!
0. absztrakciós szint - az ősember almái
Az ősember jó ideig nem tudott számolni. Számára a dolgok valóságosak, konkrétak voltak. Amikor 2 almát fogott 2 kezében, nem hiszem, hogy ennek számszakilag tudatában lett volna. Valahogy azt gondolhatta, hogy "ezzel a kezemmel almát fogok és azzal a kezemmel almát fogok". Azaz nyilvánvalósága ellenére sem összegezte az almák számát (hiszen nem volt számfogalma).
1. absztrakciós szint - az ősember 2 almája
Az első komoly lépést az jelentette, hogy észrevett bizonyos elvontabb törvényszerűségeket. Például a 2 kéz mennyisége egyenlő a 2 alma mennyiségével. Sőt, 1 alma nem egyenlő 2 almával.
2. absztrakciós szint - az ősember 1+1 almája
Rájött arra, hogy 1 + 1 = 2 művelete más dolgok esetében is működik, mint kéz vagy alma. Ez volt az igazán sorsfordító absztrakciós lépés: az ősember feltalálta a matematikát. (Persze még nem így jelölte, de akár rovátkákat húzott, akár bármi más szimbólumot használt fel, a számfogalmiság létrejött.) Nem kívánom lebecsülni az emberiségre ezután ömlő matematikai apparátust, de szerintem az 1 + 1 felismerése volt a legnehezebb lépés.
3. absztrakciós szint - az írás megjelenése
Az írás feltalálásával sok egyéb mellett a matematikai felismerések is rögzíthetővé, ezáltal reprodukálhatóvá váltak.
4. absztrakciós szint - 1+1 művelet gépesítése
Hosszú évezredekig nem volt változás az absztrakciós szintben, bár ezen vélekedés ellen a matematikusok joggal tiltakoznának, hiszen a matematika azért egyre fejlettebbé és bonyolultabbá vált. De hát mi is a matematika, ha nem a világ absztrakt leírása? Ebből következően a matematika tulajdonképpen a világ folyamatainak egyre bonyolultabb, egyre általánosabb modellezése. A tudomány fejlődésével pedig felmerült az igény a matematika gépesítésére (Charles Babbage). Én ezt tartom a következő meghatározó absztrakciós szintnek: mi módon lehet az 1 + 1 műveletet gépesíteni?
5. absztrakciós szint - a programozási nyelvek
Már nyakig benne vagyunk a modern korban, persze még nem a Java-nyelv korszakában. A számítógép architektúrájának és működésének rendező-, alapelvei alapjában véve helyesek voltak. Ha nem lettek volna azok, már felmerült volna az igény megváltoztatásukra, illetve meglehet: nagyobb kapacitásnál és terhelésnél működési zavarokat is okoztak volna. Természetesen kezdetben programozási nyelvek sem léteztek, helyette a technikusok elektroncsövek huzaljait ráncigálták egyik csatlakozóból a másikba, ám ezen áldatlan korszaknak hamar vége lett, hiszen a hardver erősödése és gyorsulása életre keltette a programozási nyelveket. Ez a következő absztrakciós szint: a világ dolgait a programozási nyelven keresztül le kellett fordítani a számítógép nyelvére, a gépi kódra. Visszatérve az eredeti példához (pszeudokód):
int a = 1;
int b = 1;
int c = a + b;
Print(c);
6. absztrakciós szint - a programozási nyelvek belső fejlődése
Óriási fejlődésen mentek keresztül a programozási nyelvek is. De önmagában sohasem a nyelv fejlődött, hanem először mindig a szemlélet, amely később egy programozási nyelvben testesült meg. Így fejlődött a programozási szemlélet a kezdeti, alapjában véve szekvenciális kódléptetéstől a már bonyolultabb programstruktúrákat biztosító moduláris programozáson át az egészen absztrakt, osztály-központú, objektumorientált szemléletig. Itt nem kívánok külön absztrakciós rétegeket definiálni, ezért eme hosszadalmas fejlődést egy absztrakciós szintnek veszem.
A legutolsó absztrakciós szinten jelenik meg az eleddig legfejlettebb, objektumorientált szemlélet, amelynek talán legfontosabb rendszerszervező alkotóegysége az osztály (class).
Az osztály fogalma
Az osztály a való élet egy szeletének olyan kiemelése, absztrakciója, amely számunkra valamilyen módon hasznos, illetve további lényeges szempont, hogy ezen tulajdonságokat fel szeretnénk dolgozni számítógéppel.
Belátom, ez nagyon ködös meghatározás, ezért gyorsan ugorjunk bele egy konkrét példába!
Adott egy Ember osztály:
public class Ember{
...
}
A definíció így önmagában semmit nem ér. Azért definiálunk egy Ember osztályt, mert fel szeretnénk dolgozni az Ember egy vagy több számunkra fontos tulajdonságát. Például szeretnénk az Ember bérszámfejtését gépesíteni. Ez így élből elég ostobán hangzik, helyette praktikusabb, ha mondjuk az osztályt célorientáltan Munkavallalo néven illetjük:
public class Munkavallalo{
...
}
Ez már elnevezésében is közelebb áll a megoldandó feladathoz. A következő annak megállapítása, hogy milyen bemeneti adatok szükségesek a munkavállalótól az eredményes bérszámfejtéshez?
Bérszámfejtő programot még nem írtam, ám bizonyos vagyok benne, hogy nem szükséges a munkavállaló számos, egyébiránt más esetekben fontos tulajdonsága:
-
cipőmérete,
-
alvási szokásai,
-
bankbetétének adatai,
-
stb.
Helyette viszont nagy valószínűséggel szükséges:
-
teljes neve,
-
anyja neve,
-
születési dátuma,
-
TB-száma,
-
adószáma,
-
stb.
Ezért az osztályt ezekkel a bemeneti adatokkal bővítjük ki:
public class Munkavallalo{
String keresztNev;
String vezetekNev;
String anyaNev;
int fizetes;
stb.
}
(A fenti pszeudokód csak szemléltető eszköz, ezért nem foglalkozunk mélyebben a deklarált adattípusok megfelelő megválasztásával.)
Nyilvánvalóan a korrekt bérszámfejtéshez más bemeneti adatok is szükségesek, például:
-
törvények,
-
munkajogi szabályok,
-
adókulcsok,
-
egyéb járuléki rendelkezések,
-
stb.,
...ám nem volna célszerű ezeket a Munkavallalo osztályban deklarálni, hiszen alapvetően nem oda tartoznak, ezért ottani deklarálásuk jelentős mértékben rontaná a magasabb szempontú kódrendezettséget. Például az összes adóval kapcsolatos bemeneti adat mehetne egy külön Ado osztályba:
public class Ado{
...
}
Másfelől a Munkavallalo osztály nemcsak munkavállaló-specifikus bemeneti adatokat, hanem vele kapcsolatos műveleteket (metódusokat) is tartalmazhat, például adatellenőrzést.
(Itt és most megint nem tárgyaljuk, hogy nem érdemes-e inkább egy külön Ellenorzes osztályban definiálni vagy a munkavállaló bemeneti adatainak ellenőrzését külön metódusokban hagyjuk a Munkavallalo osztályban.)
public class Munkavallalo{
String keresztNev;
String vezetekNev;
String anyaNev;
int fizetes;
stb.
ellenorzoMetodus1(){
}
ellenorzoMetodus2(){
}
}
Összefoglalva: az osztály a valóság egy adott, számunkra éppen fontos szeletének elvont, de a számítógép számára egzakt módon feldolgozható leképezése. Sok-sok osztályból, mint "sok-sok valóságszeletből" felépíthető egy magasabb szintű valóságleképezés, például virtuális valóság (szimuláció). Fontos azonban észrevennünk, hogy bár a virtuális valóság nagyon részletesre sikerülhet, mégsem adhatja ki a teljes valóságot.
Ha például a bérszámfejtő program helyesen kerül megvalósításra, akkor korrekt, naprakész és egzakt módon szimulálni fogja:
-
a munkáltató és a munkavállaló,
-
a munkáltató és az állam,
-
a munkavállaló és az állam
közti bonyolult, adó-, és polgári jogi törvényekkel, valamint egyéb rendelkezésekkel szabályozott pénzügyi és munkajogi kapcsolatot.
Még egyszerűbb dolgunk van, ha a szimuláció fogalmát szimulátorokon keresztül próbáljuk megérteni. Adott például egy repülőgép-szimulátor:
Ennek a szoftvernek (tágabb értelemben a létrehozó programozó csapatnak) rengeteg dolgot kell ismernie a repülésről ahhoz, hogy a szimuláció hiteles legyen felhasználója számára, ám abban bizonyos vagyok: a szoftver nem lesz képes például bérszámfejteni, hiszen a repülési szimuláció megalkotásakor a valóságnak az a másik szelete (bérszámfejtés) nem lényeges.
Pénzes László