Weblabor

Az objektumorientált programozás egyik legfontosabb előnyeként tartjuk számon a kód újrahasznosíthatóságát. A napokban egy fórumban szál formájában itt a weblaboron is terítékre került ez a téma, és többektől elhangzott az a vélemény, hogy ugyanolyan könnyen lehet eljárás központú megközelítéssel újra felhasználható építő kockákat létrehozni, mint az objektumorientált eszközökkel. Ezt a témát járná körül ez a cikk, melynek alapját eredetileg belső oktatási célokra írtam meg egy Sitepointos bejegyzés által indíttatva.

Jelen írásnak nem célja az olvasót bevezetni az OOP-ba, ezért a megértéshez szükséges egy már minimális tudás ezen a területen, de tényleg elég, ha az alapokkal tisztában vagyunk. Ezenkívül szeretném megemlíteni, hogy a cikk elsősorban PHP nyelvre vonatkozik, de megállapításainak többsége egyéb nyelvekre is igaz. Mielőtt kifejezetten a bevezetésben szereplő témát kezdenénk el boncolgatni, a teljesség kedvéért említsük meg az OOP többi alapvető tulajdonságát, és hogy ezek milyen előnyökkel járnak programjaink írása során az eljárás központú megvalósítással szemben.

Egységbezárás, információ elrejtés

Az egységbezárás (encapsulation) azt jelenti, hogy a procedurális megközelítéssel ellentétben az adatok és a függvények a program nem különálló részét képezik, hanem azok egy egységes egészként jelennek meg, összetartoznak: együtt alkotnak egy objektumot. Az információ elrejtés (information hiding) azt jelenti, hogy az objektum felhasználójának nem kell tudnia arról, hogy az belsőleg hogyan működik, csak azt, hogy milyen funkcionalitást valósít meg, mi a felülete (interface).

Programozás szempontjából ennek több előnye is van az eljárás központú megközelítéssel szemben. Először is a különböző program részek közötti kötöttség lényegesen csökkenthető, és ennek biztosítására, kikényszerítésére nyelvi eszközöket is kapunk. Egy modul készítése esetén nem tudjuk elérni, hogy annak felhasználója esetleg nem megfelelő módon alkalmazza, ami inkonzisztens állapothoz vezethet. Egy objektum esetén (a PHP 5-ös verziójától kezdve) szabályozni tudjuk a benne lévő változók és metódusok láthatóságát, biztosítani tudjuk, hogy a programozó az objektumot csak annak felületén keresztül tudja felhasználni.

A fentiből következik egy másik fontos előny is: az osztályunk belső működését bármikor tetszés szerint megváltoztathatjuk, amennyiben biztosított, hogy annak felülete változatlan marad. Ez azt eredményezi, hogy programunk sokkal rugalmasabban és nem utolsó sorban biztonságosabban átalakítható későbbi igények esetén. Például könnyen előfordulhat, hogy hatékonysági szempontok miatt szeretnénk a belső adattárolási formátumot megváltoztatni: OOP esetben csak arra kell figyelnünk, hogy az interfész ne változzon meg, míg procedurális megközelítésben ez jóval nagyobb körültekintést igényel, ráadásul a változtatások akár elsőre nem gondolt programrészekre is hatással lehetnek.

Polimorfizmus, dinamikus kötés

A polimorfizmus általában az OOP-vel ismerkedők számára egy nehezebben megfogható fogalom, ezért közelítsük meg egy példán keresztül. Most jöhetne a sokak által ismerős alakzatok kirajzolása téma, de nem, mi elsősorban webprogramozással foglalkozunk (és mind egyéniségek vagyunk), ezért nézzünk egy testhez állóbb példát: űrlap megjelenítése.

A feladatot korlátozzuk arra, hogy szeretnénk az űrlap elemeit szépen, sorrendben megjeleníteni. Az eljárás központú megvalósítás nagyjából a következő lenne: az elemeket egy tömbben tároljuk, melynek minden egyes elem szintén egy tömb, mely tárolja az adott elem típusát és az egyéb, típusra jellemző adatokat. Minden egyes típushoz tartozik egy őt megjeleníteni képes függvény. Az űrlap megjelenítő eljárásunk a következőképpen nézhetne ki:A fenti kód nem szorul túlzott magyarázatra, ezért nézzünk is meg egy lehetséges OOP megvalósítást.Definiálunk egy Form és egy FormItemBase osztályt. Az előbbi show() metódusa csak annyit csinál, hogy a paraméterül kapott űrlap elemeken (melyek mind a FormItemBase leszármazottai) végig iterál, és meghívja azok show tagfüggvényét. A polimorfizmus jelen esetben azt jelenti, hogy a Form osztály ugyan FormItemBase elemeket vár, de mi tetszőleges, ebből az osztályból származó elemet átadhatunk, mivel ezek képesek az ősüknek megfelelő módon viselkedni (az ő felületük tartalmazza az ős felületét). A Form show metódusa minden esetben az aktuális elem show metódusát hívja meg, de hogy ez éppen egy Radio elemé lesz vagy esetleg egy Select elemé, az csak futásidőben fog eldőlni, ezt nevezzük dinamikus kötésnek.

Milyen előnyt jelent ez számunkra? Eljárás központú megközelítésben minden esetben, amikor egy új (übercsászárkirály AJAX-os) elem típust szeretnénk támogatni, akkor módosítanunk kell a showForm függvényt, valamint meg kell valósítanunk az adott típusra jellemző kirajzoló eljárást. OOP megközelítésban a Form osztály show metódusa érintetlen marad, elegendő csak az új típusnak megfelelő osztályt származtatnunk. El tudtunk készíteni egy általános megjelenítő algoritmust, mely a maga számára szükséges elvárásokat egy alap elem osztály segítségével képes előírni, ezután az utólagos bővítések során már csak az elem specifikus kódokat kell megírnunk.

Kód újrahasznosítása

Az objektumorientált környezetben való kód újrahasznosítás különböző lehetőségeit fogjuk szemügyre venni, mindegyik esetben megmutatva, hogy az adott lehetőség milyen módon oldható meg eljárás központú programozás eszközeivel (amennyiben létezik ilyen). Alapvetően három esetet fogunk megvizsgálni.

Objektum példányosítás

Ezt tekinthetjük az újrahasznosítás legegyszerűbb módjának. Egy adott funkcionalítást megvalósítunk egy osztályban, majd bármikor szükség esetén létrehozunk belőle egy példányt, és használjuk. Ez alapvetően nem több, mint ha procedurális megközelítésben készítenénk egy modult. Talán az OOP kód
szemléletesebb: query($database, $sql) kontra $database->query($sql), de ez erősen személyfüggő.

Öröklődés

Az öröklődés során származtatással hozunk létre egy már meglévő osztályból egy újat, amely rendelkezni fog az ős minden tulajdonságával, és nekünk csak a kívánt plusz funkciókat kell megvalósítanunk. A következő pontok ennek tipikus eseteit taglalják.

Absztrakt osztály

Absztrakt osztályokkal alapvetően egy felületet definálunk, amlyet a leszármazott osztálynak meg kell valósítani. Ezt is elérhetnénk eljárás központú megközelítésben, de csak úgy, hogy szövegesen dokumentáljuk, hogy egy adott felület megvalósításához milyen függvényeket kell létrehoznunk, a mi felelősségünk, hogy ezt meg is tegyük. Absztrakt osztály használatával ezt már fordítási időben ki tudjuk kényszeríteni. Nem megfelelő implementáció esetén programunk le se fordul, tehát egy plusz nyelvi eszközt kapunk ennek kikényszerítésére.

Osztály kibővítése

Ebben az esetben szeretnénk egy már meglévő funkcionalítást valamilyen szempontok alapján kiegészíteni. Eljárás központú megközelítésben is tudunk egy már meglévő modulunkból egy újat létrehozni, de ilyenkor az összes olyan függvényt, ami amúgy megfelelően működik, át kell vezessünk az új modulban egy függvényen keresztül (vagy átnevezgetjük őket, de akkor minden változtatás esetén külön figyelni kell arra, hogy a két modul konzisztens maradjon). OOP esetben ezt sokkal egyszerűbben érjük el az öröklődéssel. Ilyenkor az új osztályban csak azokat a függvényeket kell felüldefiniálni, amelyeknek a működése nem megfelelő számunkra.

Callback függvény helyett hook

Procedurális megközelítésben gyakori megoldás, hogy egy függvénynek úgynevezett callback függvényeket adunk át, amellyel előbbi működése annak megváltoztatása nélkül módosítható. Például egy rendező algoritmusnak átadjuk az elemeket összehasonlító függvényt stb..Ha egy algoritmus sok callback függvényt igényel, akkor az ilyen irányú megközelítés elég problémássá, nehezen kezelhetővé válik. Sokkal jobb megoldás, ha a funkcionalitást egy osztályba zárjuk, majd a működést befolyásolni képes részeket kihelyezzük egy-egy metódusba, és a késöbbiekben öröklődéssel és ezen függvények felüldefiniálásával érjük el a működés differenciálását.

Objektum kompozíció

Ez már az objektumorientált programozás magasabb lépcsőfoka, melynek lényege, hogy olyan osztályokat hozunk létre, melyek működése nem egy konkrét módon történhet, hanem az más osztályokkal paraméterezhető, és használatakor ezekre van szüksége a konkrét feladatának ellátáshoz. Ez által olyan építőelemeket tudunk kialakítani, amelyeket jól kombinálhatunk egymással, és eltérő variációikkal eltérő működést érhetünk el.

Nézzük meg például az algoritmusok Hello worldjén, a már előbb is szóbakerült buborék rendezés példáján keresztül, hogy miről is van szó. Körülbelül ez lenne egy tipikus OOP megvalósítás:Ezzel két gond is van:

• Csak az algoritmus futtatása miatt példányosítanunk kell egy objektumot (melynek nincsenek is tagváltozói).
  
• Ha felülírjuk a compare metódust egy származtatáskor (más típust rendezni tudó osztályt szeretnénk), akkor fenáll a veszélye, hogy magát az algorimtust is felülírjuk.
  

Ezért érdemes a két dolgot szétbontani.Ez jó példa amúgy a stratégia tervezési mintára is. Tegyük fel, hogy megvalósítunk egyéb rendező algoritmusokat is: ezek mindegyikének lenne egy compare metódusa (az ilyen algoritmusokhoz ez általában szükséges), ami az alap OOP megoldást alkalmazva annyi osztályt eredményezne, ahány algoritmusunk van szorozva a rendezendő típusok számával. Kompozíciót használva azonban az osztályok ilyen exponenciális elszaporodása megakadályozható: mindössze szükségünk lesz egy-egy osztályra a különböző fajta rendezési algoritmusokhoz, illetve kell majd egy-egy összehasonlító osztály típusonként, és ezeket szükség szerint, szabadon tudjuk kombinálni.

Nézzünk egy bonyolultabb, szemléletesebb példát. Feladat: van egy az alábbi felépítéssel bíró szöveg fájlunk (az első sor jelenti a mező neveket):Ebből generáljuk a következő kimenetet:Nézzük a feladat lépéseit:

• A fájl tartalmát be kell olvasnunk.
  
• Végig kell iterálnunk rajtuk
  
• Ki kell nyomtatnuk őket
  

Alap esetben beolvasnánnk, egy ciklussal végigmegyünk, és kiíratjuk.
Ehelyett nézzük a következő megoldást:Vegyük szemügyre lépésről lépésre.

1. A Loop osztály run metódusa első paraméterében kap egy iterátor interfészű objektumot, másodikban pedig egy LoopManipulator-út, és mindössze annyit tesz, hogy végigiterál az első paraméteren, és minden elemére meghívja a LoopManipulátor megfelelő eljárásait az alábbiak szerint.

   <?php
   class Loop {
   	// statikus
   	function run(&$iterator, &$manipulator) {
   		$index = 0;
   		$iterator->reset();
   		if ($iterator->isValid()) {
   			$manipulator->prepare();
   		}
   		for ( ; $iterator->isValid(); $iterator->next()) {
   			$current = &$iterator->getCurrent();
   			if ($index) {
   				$manipulator->between($index);
   			}
   			$manipulator->current($current, $index++);
   		}
   		if ($index) {
   			$manipulator->finish($index);
   		}
   		return $index;
   	}
   }
   ?>

2. DataFileIterator osztály egy iterátor felületet biztosít a DataFile osztályhoz.
   
3. A DataFile osztály fájl alapú táblákat képes memóriában tárolni (kb. egy tömb).
   
4. A DataFileReader képes a konkrét fájlt feldolgozni, és a DataFile objektumba belepakolni.
   
5. A MenuPrinter pedig kinyomtatja a megfelelő formában a menüt.
   4 metódust kell megvalósítania:
   
   • prepare(): iterálás előtt kerül meghívásra
     
   • between(): két elem feldolgozása között kerül meghívásra
     
   • current(): minden elemre meghívásra kerül az iterálás folyamán
     
   • finish(): az utolsó elem feldolgozása után kerül meghívásra
     

Mi az előnye ennek a látszólagos elbonyolításnak?

• Jól ekülönül az algoritmus (iterálás az elemeken), és a működés (menü nyomtatása).
  
• Az algoritmust egyszer valósítjuk meg egy általános, újrafelhasználható módon. (Gondoljunk bele, hogy hányszor írunk le egy ehhez hasonló for ciklust.)
  
• Az egyes elemek újrafelhasználhatóak.
  

Mindezen szempontokon túl kódunk lényegesen rugalmasabb lesz a későbbi esetleges változtatásokkal szemben.

1. Például megváltozik a fájl szerkezete: elég egy új DataFileReader osztályt írnunk.
   
2. Vagy mondjuk a menü bekerül textfájlból adatbázisba:

   <?php
   Loop::run(
   	new QueryIterator(
   		$database->query('select category, name, link from menu, order by category')
   	),
   	new MenuPrinter
   );
   ?>
   

Mint láthatjuk minimális módosítást kell a programunkon végezni, ráadásul ha jól megnézzük, akkor ezen elemek jó része általánosan használható, tehát ha már egyszer elkészítettük őket, akkor bármikor rendelkezésünkre állnak, bevethetjük őket. Sok apróbb, általánosabb építőelem készítésével, és ezek megfelelő kombinálhatóságával flexibilisebb kódot készíthetünk, mint ha nagyobb, teljesen specializált osztályokat alkalmaznánk. Az objektum kompozició által nyújtott kódújrafelhasználhatóság nem igazán megoldható struktúrális megközelítésben.

Programtervezési minták

A tervezési minták már némileg túl is mutatnak a kód újrahasznosításon, megoldás újrahasznosítást nyújtanak számunkra amennyiban OO módon programozunk. Ezek olyan kész, kidolgozott receptek, melyeket adott problémák esetében bármikor bátran bevethetünk: ezek az adott feladtra jól bevált, kidolgozott megoldást nyújtanak. Egyik előnyük így adott is, ha felismerjük, hogy adott szituációban egyikük-másikuk használható, akkor egy komoly mankót, kész vázat kapunk az kezünkbe. Ezenkívül egy másik, nem annyira egyértelmű pluszt jelent az, hogy egy egységesen használható fogalom tárat is jelentenek, mely megkönnyíti a fejlesztők közötti kommunikációt.

Körülbelül ennyit szerettem volna elmondani, remélem, hogy sikerült némileg bizonyítani, hogy az OOP nem egy öncélú, elefántcsont toronyba való szemléletmód, hanem egy nagyon is hasznos, relatíve könnyen "készpénzre" váltható, hatékony eszköz; érdemes némi energiát fektetni a megismerésébe, mert sokkal kifejezőbb, rugalmasabb, könnyebben módosítható programokat fogunk tudni írni alkalmazásával.