ugrás a tartalomhoz

Egyszerű plugin kezelő - OOP gyakorláshoz

dorten · 2012. Jan. 7. (Szo), 21.38
Üdv Weblaborosok!

Egy ideje rajtavagyok, hogy elsajátítsam az OOP ismereteket. Ebben kérnék egy kis segítséget. Gyakorlásképpen elhatároztam, hogy készítek egy egyszerű, pluginokkal bővíthető, amolyan "funkciókatbele" osztályt. Ebből az osztályból építkezhetnének a meghívott modulok. Készítettem egy rajzot, hogy jobban értsétek: itt
Elképzelés van, de nem tudom, hogyan kössem össze az osztályokat. Azt szeretném, hogy a betöltött pluginokat (php fájlokat, osztály-funkció van benne) fel tudjam használni a "funkciók" osztályba, és az aktív modul pedig a funkciókat és a plugin osztályokat is el tudja érni. Lehet kicsit kusza, de ott a rajz :)

A segítséget, tanácsokat előre is köszönöm!
Roland
‹ Php függvény szerver teljesítmény Lekérdezés több sorral való megfeleltetéssel ›
 ■
1

Erre a feladatra event-eket

Kubi · 2012. Jan. 7. (Szo), 22.32
Erre a feladatra event-eket kellene használnod.

Egy példa: az aktuális modulodnak, ami legyen a hír listázó, kell lehetőséget adnod, hogy pluginnel kilehessen bővíteni. A hírlistázás folyamata:
- db adatok lekérdezése (getDbData),
- db adatok feldolgozása (egy tömb létrehozása, melyben benne van minden hír az adataival, processDbData),
- adatok megjelenítése (renderData)

Az egyes részeknél, a lefuttatása előtt és után is dobsz egy eventet, pl.: hirek.preGetDbData, hirek.postGetDbData stb. Az eventnek átadod az aktuális adatokat, hogy módosítani lehessen, pl hirek.preGetDbData, átadod az url-t, hirek.postGetDbData, átadot a db adatokat stb.

Ezzel a megoldással az eventekre feltudnak iratkozni a pluginjeid és a megadott kódot lefuttatni.

Eventek készítéséhez némi segédlet:

Ha magad akarod megcsinálni, egyszerűbb formában, akkor nézz utána az observer patter-nek,

ha külső megoldást akarsz felhsználni (csak hogy ne találd fel újra a spanyol viaszt) http://components.symfony-project.org/event-dispatcher/ ezt használhatod.

Ez nem egy egyszerű feladat, kitartást hozzá.

Ha már ennyire bele akarsz mélyedni az oop-ba, kezdj el egy oop frameworkel dolgozni. Symfony-t ajánlom :) 1.4 könnyebb, 2.0 nehezebb. Symfony-ban benne van az event kezelés is :)
2

Köszönöm, ezek nagyon hasznos

dorten · 2012. Jan. 7. (Szo), 22.54
Köszönöm, ezek nagyon hasznos infók voltak.
Egyébként lehet, hogy kicsit félreérthetően fogalmaztam, de én nem azt szeretném, hogy a pluginek belenyúlnak a modulokba, csupán annyit, hogy bővíteni lehessen a "funkciók" osztály fegyvertárát :) Írtam, hogy például egy plugin fájl betöltésével már lehetőség van bbcode formázásra. Szóval ilyen "apróságok".
3

aham, ebben az esetben a

Kubi · 2012. Jan. 7. (Szo), 23.25
aham, ebben az esetben a __call magic függvényt használhatod (ha most nem értelek fére). A php az objektum __call metódusát hívja meg minden olyan esetben, ha az adott függvény nem létezik az objektumban.

Annyit azért hozzátennék, hogy így első hallásra nem egy szép megoldás. Ne akarj mindent egy osztályba tenni, jó ha külön vannak, ha csak azért használsz classokat, hogy egymástól független kódrészleteket gyüjts egybe, akkor public static function -ként vedd fel őket, így nem kell példányosítani az objektumokat. Amúgy az oop nem erről szól :)

Használj autoloader-t php autoloading így nem szükséges az include sorok használata.

class pluginContainer
{
  protected $plugins = array();

  public function addPlugin($plugin)
  {
     $thsi->plugins[] = $plugin;
  }

  public function __call($method, $arguments)
  {
     foreach($this->plugins as $plugin)
     {
        if(method_exist($plugin, $method)
        {
           return call_user_func_array(array($plugin, $method), $arguments);
        }
     }
     throw new Exception($method.' not found');
  }
}
nem próbáltam ki a kódot, lehet benne hiba.

ötlet: kezdetnek adatbázis kezeléshez kezd el használni a doctrine 1.2-t, sokat tanulhatsz belőle.
4

Egyelőre még nem tudom,

dorten · 2012. Jan. 8. (V), 01.01
Egyelőre még nem tudom, milyen megoldást kellene alkalmaznom.
Akkor adott egy plugin, most valami egyszerű:

class OkosPlugin {
    public function Ossz($mit, mivel = null) { print $mit/$mivel; }
}
Egy funkció a "fegyvertárból":

class BeepitettFunkciok {
    public function Szorozz($one, $two = null) { print $one*$two; }
}
És akkor jön a modul, amelynek szüksége lenne az osztásra és a szorzásra is, és ki is bújt a szög a zsákból, én elszeretném kerülni a global $xyz mókázást - több okból is, teszemazt egy komolyabb modul 10+ funkcióval már necces. Helyette szépen, a betöltött pluginokat és a beépített funkciókat egy adott helyről tudnám elérni. Talán nem is plugin lenne erre a megfelelő szó, hanem inkább bővítmény... Nehéz eset vagyok, neharagudjatok! :-)
6

Nem értem, miért kellene

Kubi · 2012. Jan. 8. (V), 20.09
Nem értem, miért kellene neked ide a global $xyz?
A példádnál maradva van a két classod, és te eszt szeretnéd:

class module
{
  public fuction dosomething($a, $b)
  { 
    $c = OkosPlugin::Ossz($a, $b);
    $c = BeepitettFunkciok::Szorozz($c, $b);
    return $c;
  }
}
- használj a plugineknél static metódusokat (public static function)
- ha példányosítanod kell (fenti példában nincs erre szükség), viszont elég csak egy példány, használj singleton-t
- használj autoloadert

ha csak ennyit szeretnél, nem kell túlbonyolítani.
7

OOP

MadBence · 2012. Jan. 8. (V), 20.21
Mondjuk így (static metódusok, singleton) semmi köze nem lesz az OOP-hez :)
8

nem, ez tény, de ahogy nézem

Kubi · 2012. Jan. 8. (V), 23.20
nem, ez tény, de ahogy nézem nem is az itt az elsődleges célja, hanem csak függvények használata.
9

Pont, hogy elszeretném

dorten · 2012. Jan. 9. (H), 00.26
Pont, hogy elszeretném kerülni a globalozást. Igen, a Valami::Funkcio bennem is felvetődött, csak hát nem túl "szép". Ezért is kértem segítséget, hogyan tudnám összekapcsolni itt a dolgokat. :-)

Elképzeles? Az van... Végiggondolva és felhasználva a leírtakat, lehet hogy jobb lenne ha kapásból a fő funkciók osztály töltené be a pluginokat, nem tudom.
10

amiket itt használni

Kubi · 2012. Jan. 9. (H), 01.10
amiket itt használni szeretnér, úgy érzem simán nevezhetjük helper-eknek, eljárásgyüjtemény. Ezeket nyugodtan tedd egy classba, static metódusként, teljessen jók lesznek úgy.
11

Még mindig nem értem, ez így

MadBence · 2012. Jan. 9. (H), 02.42
Még mindig nem értem, ez így minden, csak nem objektum-orientált programozás :). Minek berakni egy osztályba ezeket? Maximum divat, mert ha php függvényeket írsz, azok is pont ugyanezt fogják tudni, csak még gépelni sem kell hozzájuk olyan sokat.
12

Igazatok van, tökéletesen jó

dorten · 2012. Jan. 9. (H), 15.17
Igazatok van, tökéletesen jó lesz a helper megközelítés. Felesleges ágyúval lőni bolhára. Végülis tanulva lett az esetből, ígyhát megérte. Köszönöm a segítséget! :-)
13

azért jó betenni egy classba,

Kubi · 2012. Jan. 9. (H), 15.36
azért jó betenni egy classba, de csak akkor, ha van autoloading-od beállítva, nem kell includeolni, lib mappád átmozgatása esetén is csak az autolodingot kell átírni. Kb. ennyi az előnye, de ez viszont hasznos.
5

Helló! Én javaslom, hogy a

Karvaly84 · 2012. Jan. 8. (V), 01.22
Helló!

Én javaslom, hogy a tervezést kezd egy jobb módszerrel. Pl. rajzolj egy nagy téglalapot, ebbe rétegeket, a pluginoknak, a runtimenak, építsd bele a modulokat, jobb képet ad mint a nyilazott rajzod. De az UML diagram sem egy rossz megoldás, szabványos is.

Továbbá lehet bennem van a hiba, de a funkciók, pluginek, modulok, nekem nem áll össze. Ha baromságot írok majd kijavítanak, de szerintem a legalsó szintre kel egy újra hasznosítható elemeket tartalmazó osztály könyvtár - téglalap 0. szint - amiből mindenki táplálkozik. Ki dolgozol ez fölé - téglalap 1. szint - egy runtime vagy vezérlő egységet tök mindegy minek nevezem. Ez a vezérlő mondjuk lehet egy egyszerű MVC réteg, amiben van a modul betöltő, vagy plugin betöltő. az okos függvények vannak a 0. szinten. a modulok vannak egy konténerben ahonnan beszipkázod őket a runtime adott példányába. vagy valami ilyesmi.