Gyakorlati alapok III.
Kitérő: a szoftverkrízis avagy az OO szükségessége
Ebben a fejezetben kis kitérőt teszünk az osztálynak, tágabb értelemben az objektumorientált szemléletmódnak (gyakran nevezik OO-paradigmának) további magyarázatára. Ezt megpróbáljuk újfent egyszerű, a laikusok számára is felfogható gondolatokkal megfogalmazni, amelynek persze lesznek korlátai.
Talán nem túlzás azt állítani, hogy szinte minden fejlődés hajtómotorja valamilyen kényszer. A számítógép hardverelemeinek valójában rendkívül gyors változása, az új technológiák villámgyors elterjedése, sőt a programok egyre növekvő bonyolultsága folyamatos fejlesztési kényszert helyez a programozók vállára. Aki ebbe a versenybe nem száll be, az hosszabb távon csakis veszíthet, mert lemarad a technológiai fejlődésről. Az összes informatikai cég tisztában van ezzel, ezért is működik mindegyiknél egy külön R & D (research and developement - kutatás és fejlesztés) részleg, ha nem egy egész kutatási centrum.
Ha az elavult szoftver többé nem képes a hardvert kiszolgálni vagy azt csak nagy áldozatok, például jelentős erőforrás-elvonás vagy hibák árán, illetve a szoftver valamilyen okból funkcionálisan már nem képes teljesíteni feladatát, akkor szoftverkrízisről beszélünk.
A szoftverkrízist azonban sokszor értelmezhetjük mélyebb technológiai válságnak, hiszen nem csupán arról van szó, hogy adott célszoftver nem kezeli le a célhardvert, hanem a probléma megoldásához már gyökeresen új programozási szemléletre van szükség. A világ jónéhány ilyen szoftverkrízist átélt már, jóllehet a laikus felhasználó ebből semmit sem tapasztalt meg.
Ahhoz, hogy tovább pontosítsuk a szoftverkrízis fogalmát, el kell mélyednünk a szoftverek felé támasztott elméleti követelményekben. Angster Erzsébet Az objektumorientált tervezés és programozás alapjai című könyvében...
...következő követelményeket fogalmazza meg. A szoftver legyen:
-
bővíthető
-
ellenőrizhető
-
felhasználóbarát
-
hatékony
-
helyes
-
hibatűrő
-
karbantartható
-
hordozható
-
kompatibilis
-
sérthetetlen
-
szabványos
-
szoftver minőség
-
újrafelhasználható
A fenti szempontokhoz én a következő érveléseket fűzném:
Bővíthető, karbantartható, újrafelhasználható
Ezek a szempontok lényegében összefüggnek. Ellentétben Leonardo da Vinci Mona Lisa című festményével...
...a szoftvernek enyhén szólva nem előnyös, ha egyszeri és megismételhetetlen, sőt: fejlesztője számára létkérdés gyors karbantarthatósága, illetve ha a megírt kódok más helyen, más projektben, más szoftverben szintén felhasználhatók. Nyilvánvalóan a szoftver minél modulárisabb, annál könnyebb rajta bármit lecserélni, kijavítani, kiegészíteni, hasonlóan az autókhoz: az elemek döntő többsége ott is cserélhető, javítható, bővíthető. Jól néznénk ki, ha az autó egyetlen masszív, összehegesztett tárgyként üzemelne!
Szabványos, kompatibilis
A szabványosság és kompatibilitás kissé problematikus kérdés, hiszen a legelső, úttörő szoftverek és programozási paradigmák esetében még nem beszélhetünk szabványokról és bármerre is törekvő kompatibilitásról. A kompatibilitás alapjában véve, főleg a felhasználó szempontjából jogos elvárás (például új MS Word nyissa meg a régi .doc verziókat is), ám ennek létezik egy határozott, de mégis nehezen megfogalmazható határa, amelynek alapja mégis a szoftvercégek nyűggel teli, együttműködési kényszere (mert hiszen mindegyik egyeduralomra törne, ha ezt megtehetné és akkor már nem volna értelme kompatibilitásról beszélni).
A szoftver-szabványosság manapság még szintoly ködös fogalom, mint a kompatibilitás, bár nélküle hamar káoszba fulladna a szoftvertervezés, éppen ezért a szabványosságra való törekvés jól felfogott, önös érdekből tetten érhető a legtöbb szoftvercégnél. Gondoljunk csak a Windows szabványosnak mondható kezelőfelületeire.
Felhasználóbarát
Ha a szoftver használata során nem válik a felhasználó barátjává, akkor előbb-utóbb nem lesz ki használja, a fejlesztő tehát hosszabb távon magát a megrendelőt veszíti el. Ebből következően a célszoftver mindig a megrendelő igényeihez igazított. Felhasználóbarát és szabványos szoftver fogalmak lényegében összetartoznak, mert az a legelőnyösebb, ha a felhasználó minden funkciót mindig ugyanott talál meg és ez nem teljesíthető, ha nincsenek a szoftver-szabványok legalább "házon belül", azaz fejlesztő cégben lefektetve. A probléma az, hogy minél tágabb közönséget céloz meg a szoftverfejlesztő, cserébe annál több reklamációt várhat, következésképpen nincs olyan szoftver, amely mindenkinek egyformán tetszene.
Hatékony, helyes, hibatűrő
Ezen a tulajdonságok a szoftver alapfunkcionalitásához tartoznak. A legalapvetőbb elvárás a szoftver felé, hogy szolgáltasson helyes eredményeket, ha pedig erre nem képes (például elfogyott a műveleti memória), tájékoztassa erről a felhasználót és tegye meg a szükséges lépéseket a biztonságos leállásra. Persze az is igaz, hogy mégsem lehet lekódolni minden szoftverben minden lehetséges hibareakciót, az optimális szoftvertervezés tehát szorosan összefügg a hatékonysággal is.
Hordozható
A szoftver hordozható, ha különböző hardver-, és szoftverkörnyezetben is megőrzi funkcionalitását. Ám a meghatározások megint elmosódottak, hiszen linuxos program nem fog működni windows-os gépen, a hordozhatóság fogalma tehát további pontosításokat igényelne, amit most nem teszünk meg.
Amint érezhető, a fenti kritériumok fontos és jogos elvárások, mégis pusztán elméleti megközelítések, mert a tudomány jelenlegi állása szerint nincs olyan szoftver, amely a fenti elvárások mindegyikének maradéktalanul megfelelne.
A felsorolást mégis hasznosnak értékelhetjük, mert általa érzékelhetjük a szoftverfejlesztés szempontjainak egyre növekvő bonyolultságát, amely szakmai kihívást manapság már csak az objektumorientált szemlélet bevezetése és aktív alkalmazása képes megoldani.
Összefoglalásképpen nézzük meg a jelen pillanatban legmodernebb, objektumorientált szemlélet legfőbb jellemzőit:
-
az objektumok (osztályok) a való világ modellezése vagy egyéb absztrakció során keletkezett, számunkra fontos tulajdonságokat hordozó kódegységek - például Munkavállaló osztály egy könyvelési programban, ahol nem fontos a munkavállaló lábmérete, csupán minden olyan tulajdonsága, amely fizetésének, járulékainak könyveléséhez szükséges,
-
az objektumok csakis jól meghatározott feladat végrehajtására hivatottak, csakis az ehhez szükséges adatokat és műveleteket (metódusokat) tartalmazzák - például matematikai osztály nem fog tartalmazni hálózati metódusokat,
-
az objektumok feladatai funkcionálisan tervezettek és szétosztottak - például egy könyvelési programban külön Munkavállaló osztály, Adó osztály, Fizetés osztály, stb.
-
mivel az objektumok feladatai szétosztottak, az objektum kifelé, azaz a külvilág felé egységesen zárt, belső adatai, metódusai elérhetetlenek (a másik oldalról nézve: az objektum zártsága miatt belső hibái sem tudnak kiszivárogni),
-
az objektumok üzeneteken keresztül kommunikálnak egymással (interfészek),
-
polimorfizmus (többalakúság) - leegyszerűsítve: azonos üzenetre az objektumok különbözőképpen reagálhatnak,
-
mivel az objektumok feladatai funkcionálisan tervezettek és szétosztottak, ezek a logikus szempontok objektumok (osztályok) magasabb rendszerezése céljából is felhasználhatók (osztálykönyvtárak létrehozása),
-
az osztálykönyvtárak logikus rendszerezésével rengeteg előre megírt, kiváló minőségű kód keletkezett, a kódok nagyobb részét tehát nem szükséges megírnunk, hanem vagy beimportáljuk, vagy az öröklődés (inheritance) segítségével a számunkra előnyös tulajdonságokat származtathatunk egy másik (ős) osztályból, illetve a származtatott (utód) osztályban ezekhez a tulajdonságokhoz továbbiakat is illeszthetünk,
-
Futásidő alatti kötés - ez egy eléggé nehezen érthető fogalom. Mivel a programfunkciók nagyon jól szegmentálhatók, lehetőség van arra: ne a programozó és jóval hamarabb, a program írása során, hanem a JVM, a konkrét futásidőben döntse el, hogy melyik metódus kerüljön végrehajtásra. (Ezért nevezik késői kötésnek, amely tehát valójában futásidő alatti kötés.)
Pénzes László