Hankó Zoltán a blog rendszeres olvasója vetette fel az objektum orientált php programozás témát, így most erről fogok írni. Köszönöm az ötletet, remélem hasznos lesz. Megpróbálom leírni, én hogyan látom a dolgokat és hogy készítek oop honlapokat.
Mi volt régen
Az objektum orientált programozásról már 8 évvel ezelőtt középsuliban tanultunk először, ahol ugyan megértettem a Teglalap.terulet() metódust, de egyszerűen nem tudtam megérteni mi értelme van objektumokat létrehozni, hisz simán is írhatnék egy területszámolós függvényt.
Egyetem alatt Java, C++ kötelezővé tette az objektumok ismeretét, származtatás, gyártófüggvények és különféle diagrammok használatát. A 4-est abból is összehoztam úgy, hogy még mindig nem láttam értelmét az egésznek.
A php oldalaimat úgy készítettem el, hogy minden kérés az index.php-be futott be, aminek a közepén volt egy content.php. Ez a paraméterben kapott ?id=profil -ból eldöntötte, hogy melyik php fájlt kell a tartalom részbe betölteni, és nagyjából ettől vált dinamikussá az egész. Ami még említésre méltó az egy config fájl, illetve egy function.php ahol az összes függvény vegyítve volt tárolva. Egy deka objektum nem volt benne.
Telekikoli.hu
Sokszor elgondolkodtam azon, miért kellene átváltanom oop-re, de valahogy sosem jöttem rá. Egyszerűen nem csináltam olyan méretű projekteket ami megkövetelte volna, mindent el tudtam végezni a jelenlegi felállásban. A telekikoli.hu oldal volt az amit hobbiból elkezdtem írni, többen használták és ilyen közösségi oldal fílinget adott. El is kezdtem írni egy cikket az újraírásáról Cakephp keretrendszer használata mellett, azonban ezt félbe kellett szakítanom két okból.
Az egyik, hogy kezdődik az egyetem és a használni szeretnék, félkész munkát pedig nem adunk ki, úgyhogy gyorsabb a régi oldalt kipucolni és felturbózni. Másrészt egy ilyen oldal elkészítése nagyon nagy munka. Nem konkrétan a programozás rész, mert az az ahol 10 nap alatt bármilyen munkát megcsinálok ha van előre konkrét rendszerterv, és grafika. Nekem az oldal szerkezetének elkészítése nagy nyűg, amiről itt írtam, és a mockingbird segítségével, vagy papíron ceruzával végzek.
Lényeg a lényeg, ha elém tesznek minden oldalról egy jpg-t én egy óra alatt átnézem és összeáll a fejemben a rendszer, esek is neki a programozásnak. De lássuk csak mit csinálok abban az egy órában:
Objektumok keresése
Ha ránézek egy oldal tervre amit photoshopban elkészítettek, előveszek egy papírt ceruzát, és elkezdem leirogatni, mik azok a nagyobb dolgok amik az oldalon találhatóak. Lényegében ez az objektum keresés, csak régen nem csináltam hozzájuk objektumokat. Zavaros igaz?
Régen egy projekt mappája úgy nézett ki, hogy gyökér könyvtár, benne css, js mappa és egy private mappa. Ide pakoltam azokat a fájlokat, amikből lényegében összeállt az oldal. Ha a telekikolin volt egy rész ahol bulira lehetett jelentkezni, akkor általában volt egy buli.php ami kezelte a kéréseket és attól függően hogy mit szerettél volna csinálni, betöltötte a buli_view.php-t vagy a buli_edit.php-t.
Aki belenézett egy ilyen mappába láthatta a kis csoportokat amik ugyanazzal az előtaggal kezdőttek és a végük mondta meg hogy konkrétan mi a feladatuk, pl apro_venne, hirek_index, kolicsere_delete. És láss csodát működött a rendszer, és nekem kb 4 másodpercig tartott lokalizálni melyik fájlba is kell belenyúlnom, annak melyik részét kell javítanom. Pusztán megszokás kérdése volt.
Persze nem volt mindig egységes elnevezés, mikor milyen időszakom volt, de mindig átláttam, ha másképp nem, végigkövettem az egészet mint egy böngésző, miket töltök be, hol minek kellene lennie. A lényeg: működött, és lehetett bővíteni.
A váltás
Az utóbbi időben kaptam pár munkát, ahol Code Igniter vagy Cakephp keretrendszert használva kellett honlapot készíteni. Ezekben az embernek nincs választása, objektum orientáltan kell programozni. Meddig tartott megtanulnom az alapokat? 2 nap, talán 3. Ez idő alatt megértettem miért érdemes használni ezeket, és hogy igazából nem is különbözik sokban attól, amit eddig én csináltam, puszán sokkal rendezettebb.
Objektumok keresése ismét
Az előbb megint elkanyarodtam az objektumoktól de térjünk vissza rájuk. Honnan tudom hogy valami objektum?
A figyelmeztetés azért is fontos, mert nem mindig azokat a dolgokat kell használni amik a legjobbak. Márkus oldalán sincs egy darab objektum, mégis ellátja a feladatát. Talán 1 órával tartott volna az egész és 8 megával lenne nagyobb, de minek dolgozni feleslegesen. Tipikus esete a bolhára lövünk ágyuval dolognak.
Honnan tudom hogy valami objektum
Kerülgetem itt a forró kását nagy kitérőkkel, de felelősségteljes dolog ez, óvatosan kell mint a szűz lánnyal. Én leülök, ránézek a képre és belegondolok hogy ha felhasználó lennék, miket csinálnék. Mik azok a dolgok amikhez adatbevitelre vagy adatbázisból való lekérésre van szükség.
Ugyanis, ha ezek megvannak, akkor már egy csomó objektumot megtaláltunk. Az abjektumok többsége metódusokat és értékeket is tartalmaznak, ezeket pedig nagyrászt adatbázis táblákból nyerik. Ha megvannak a táblák, megvannak az objektumok. Legalábbis a többségük. Nézzünk példákat:
Users
A legtöbb oldalon van bejelentkezés, felhasználói profil. Ehhez létrehozunk egy táblát mondjuk users néven. Többesszámot azért használok tábláknál, mivel felhasználókat tárol, és ennek egy sora a felhasználó.
Posts
Tegyük fel, hogy mindenki tud cikket írni, ezeket is táblában tároljuk, szintén többesszámot használva. Megint egy objektum.
Comments
A felhasználók hozzá tudnak szólni a cikkekhez, ezért egy ilyen táblánk is lesz, plusz objektum.
Posts_users
Ez mi a nyavaja? Egy cikkhez több felhasználó is hozzászólhat, és egy felhasználó több cikkhez is fűzhet hozzászólást. Ha le akarnám kérni, hogy én mihez szóltam hozzá, vagy hogy ehhez a cikkhez kik szóltak hozzá, akkor egy olyan táblára van szükségem ami ezt segíti.
Aki még nem hallott a több-többes kapcsolatról az most bajban lesz, mivel ez pont az, érdemes rágooglezni. Tehát ez a tábla tartalmaz egy felhasználó id és cikk id párost, amik összekötik a két tábla egy-egy sorát. Ennek nem fogunk létrehozni objektumot, mert felesleges. Miért felesleges? Nagyon nem gondoltam még bele, de még sosem volt szükségem rá, ezért én annak neveztem ki, az ilyeneket egyből skippelem.
Ahol nem a táblából lesz objektum
Erre egy példa a 67developer.hu oldalon lévő contact. Nem tárolok semmit adatbázisban, amit beírtok az jön nekem emailbe. Akkor minek lett belőle objektum? Nos ez a keretrendszer egyik követelménye, legalábbis én annak nevezem.
Megint kitérő jön: egy keretrendszer arra törekszik, hogy a kódot modell, controller és view részre bontsa. A kezdő oldalamon statikus tartalom van, néhány link és egy jól sikerült kép rólam /jó volt az alapanyag/. Nem kapcsolódok adatbázishoz, nincsenek benne műveletek, ezért ez egy statikus oldal, ami csak simán megjelenik.
A contact oldal ezzel szemben a megjelenítésen kívül egy email küldés feladatot is ellát. Most erre vagy létrehozok egy function.php-t ahol a különféle függvényeket tárolom, és a contact fájl elején levizsgálom hogy elküldted -e az üzenetet, majd ha igen akkor meghívom ezt a függvényt. Vagy pedig létrehozok egy objektumot a contactnak, és annak egy metódusa fogja ellátni a feladatot.
Újfent a kérdés, miért jobb az objektum? Mert 4 másodperc helyett 1-re csökken ami alatt rájössz hol kell keresned. Másrészt ha szükséged van az email küldésre, és betöltöd hozzá a function.php-t akkor vele együtt egy csomó más függvény is betöltődik, amire nincs is szükség. Míg ha objektumokkal dolgozol, akkor nem kerül bele sok felesleges dolog.
Azért mondom, hogy nem sok, mert ha mondjuk egy felhasználó menti a profilját, akkor általában teljesen felesleges betölteni a törlés vagy listázás függvényt, márpedig ezek is hozzá tartoznak az objektumhoz. Ok, nyilván néhány byteról vagy kbról beszélünk, de mégis. Ha a régi módszeremet venném elő, ahol a buli.php megnézte hogy a paraméterben lévő ?task=save mit kíván, akkor csak a buli_save.php-t töltötte be, ami tartalmazta a mentést, és egy átirányítást valahova.
Mindennek vannak előnyei és hátrányai, az objektum orientáltság rendezetté teszi a kódot, keretrendszert használva pedig gyakorlag rákényszerít, hogy szabályokhoz tartsd magad, amik egységessé teszik a programjaidat. Nagy hibám volt például, hogy kétféle képpen kezeltem az adatbázishoz való kapcsolódást. Mikor tanultam a php-t első megvalósításom ez volt:
1. 2. 3. 4. 5. 6. | //csatlakozás az adatbázsihoz connect(); //mivel egy adatbázisban van 4 projekt, ezért a tábláknak kell egy prefix, hogy megismerjem őket, pl teleki_user $t = $mysql['prefix']."user"; $sql = "SELECT name FROM $t WHERE id = 12" |
Később a connect() függvény már kikereste a prefixet és visszaadta
1. 2. 3. | $prefix = connect() $t = $prefix."user"; ... |
Hát sok mindent nem spóroltam meg magamnak, sőt igazából nem is tudom miért csináltam, a lényeg, hogy mindig előtte meg kell néznem, hogy az adott projektben hogy is kezeltem, különben nem fog működni.
Keretrendszernél nincs ez a probléma, mivel ott egyszer megtanulod hogyan kell, és onnantól kezdve mindenhol úgy kell. Meg van kötve a kezed, de ez egy szükséges dolog.
Összegzés
Azt mondhatnád, hogy ez megint minden volt csak az nem amire kiváncsi vagy, de szerintem ezt megtanítani személyesen is csak úgy tudnám, ha megmutatnám az összes rossz kódomat amit írtam, majd az egyre jobbakat, hogy végül mindenki megértse, hogy ááá ezért kell használni!
Én úgy tanultam, hogy elvállaltam egy munkát amihez kellett, nem volt választásom éjjel nappald példákat és dokumentációt olvastam, és egyszer csak megértettem. Nincs olyan pont ahol az ember értelmét látja az egésznek, egyszerűen el kell kezdeni és jön magától.
Ami még fontos, hogy szerintem én nem használnék oop-t ha nem hazsnálnék keretrendszert. Megkönnyíti a dolgod, egy csomó terhet levesz a válladról, és igazából nem is tudatosul benned, hogy te most objektum orientáltan programozol, egyszerűen azt mondod pl hogy ez Cakephp /ami persze csak a keretrendszer, de én ezt mondom/
Amit ajánlani tudok az a Cakephp, mert szerintem egyszerű, és ebben tudok is segíteni ha kell. Sokszor elakadtam, de fórumokon mindig találtam megoldást.
Amiben még tudok segíteni, az a kódjaim megosztása. Ahogy időm lesz a saját projektek készítésével, megosztom a kódokat és mindegyikhez fűzök megjegyzést, ebből rmeélem sokat tudtok majd tanulni.