Moduláris Programozás
 
Mi is ez?
 
A moduláris programozás egy olyan folyamat, amely során a kódot felbontjuk különböző, ú.n modulokra, az alapján, hogy milyen feladatot lát el, milyen logikát tartalmaz. Itt, PAWN-ban ez annyiban nyilvánul meg, hogy ezeket a modulokat külön forrásfájlba tesszük. Ilyenkor lesz egy \"fő\" modul (itt main-nek fogom hívni) ami összekapcsolja az összes többit valamilyen beágyazó mechanizmus segítségével, amely nekünk az include direktíva.
 
 
 
Oké, de miért jó?
 
A kérdést nagyjából megválaszoltam az előző pontban az egy vagy több forrásfájlos problémával. Ennek ellenére a hasznosságát szeretném egy egyszerű példával szemléltetni.
Például, szeretnél megnézni egy-két dolgot egy gamemode-ban, hogy hogyan oldották meg. A mód egyetlen egy fájl, amely 30-40 ezer soros. Megnyitod, ránézel. Órákig tart, mire kisilabizálod, hogy egyáltalán melyik az a kódrészlet, amelyre neked szükséged van, aztán még lehet órák kérdése az is, hogy felfogd.
Felteszek egy őszinte és nagyon fontos kérdést: tetszik az ilyen? Ha igen, akkor (és most ez lehet, hogy egy kicsit durván hangzik) nem valószínű, hogy a fejlesztői pálya neked való.
Másik eset: egy nagyobb skáláju projektet tervezel, esetleg egy olyan módot szeretnél írni, ami sok színű, sok mindenre való. Ha felismered, hogy több, független feladatot lát el maga a mód, akkor egyből a rendszerezésen kell gondolkodni, valamint, hogy hogyan szeretnéd felépíteni. Viszont (és ez most egy nagyon nagy viszont), kisebb projektekre is javaslom, a következő pontban leírom, hogy miért.
 
 
 
Előnyök
 

• 
     Könnyen bővíthető rendszer kiépítése
  


• 
     Kód újrahasználhatósága (ez egy nagyon fontos pont)
  


• 
     Egyszerűen testre lehet szabni, hogy mire van szükség, mire nem
  


• 
     Rendszerezett, tisztázott kód
  


• 
     Több ember kényelmesen tud rajta dolgozni
  


• 
     Manapság az OOP nyelvek ugyan ezen az elven működnek, ezért is érdemes megismerkedni vele
  

Hátrányok
 

• 
     Azonos azonosító nevek (változók, metódusok) nem szerepelhetnek a különböző modulokban (ez a PAWN és egyéb C alapú nyelvek sajátossága, később megbeszéljük, miért)
  


• 
     Callback-ek többszöri szereplése. Ezt a jelenséget remélhetőleg a többség ismeri. Példa: az OnPlayerConnect callback használva van egy library-ben (include-ban) és a módodban is. Ilyenkor szól a fordító, hogy kétszer szerepel a callback és nem tudja eldönteni, hogy melyiknek kell előbb vagy utóbb futnia.
     Erre több megoldás létezik: ALS, YSI féle y_hooks (itt ezt fogjuk használni), egyéb include guard-ok.
  


• 
     Sokat kell dokumentálni a modulok miatt.
  

Hogyan?
 
Először is beszéljük át, hogy egy moduláris projekt hogyan is néz ki élesben.
Az alábbi képen látható egy példa:
 

Itt nyilvánvalóan a main.pwn lesz az, ami összeszedi az összeset egyben, valamint ez lesz az a fájl (ez most egy gamemode), amit a szervernek be kell hivatkozni.
A nagyobb modulokat egy mappába szervezzük, valamint minden olyan modult, amely feltétlenül szükséges ahhoz, hogy a script fusson egy core mappába egységbe zárjuk. A többi modul, amelyektől egyáltalán nem \"függ\" a script, mehet külön, ezeket \"stand-alone\" moduloknak szokás hívni.
A player core modulja tartalmazza a játékos enum-ját és egyéb definícióit, valamint azokat a metódusokat, amelyek hozzá kapcsolhatóak.
 

#include <YSI\\y_hooks> // ezt mindjárt tisztázzuk
enum playerData
{
bool:isLoggedin,
level,
...
};
new Player[MAX_PLAYERS][playerData];
...

 
 
 
Ez után, ezt fogjuk beágyazni a main-be:
 

/*==============================================================================
Libraries
==============================================================================*/
#include <a_samp> //SAMP Team
#include <YSI\\y_hooks>
/*==============================================================================
Modules
==============================================================================*/
// Player
#include \"core/player/core.pwn\"
  
...

 

...és így tovább.
Nyilván modul is behivatkozhat modult, sőt, sokkal szebb, ha nem az összes modult ágyazzuk be a main-be, hanem inkább azt mondjuk, hogy a modulok önmagukban is működnek. Ilyenkor, az adott modulba behivatkozzuk azt, amelyiktől függ.A #include jelentése
 
Mielőtt tovább mennék, beszéljük át, hogy mit is jelent az include direktíva.
Egyrészt a hashmark (#) jelzi a fordítónak, hogy ez egy preprocesszor direktíva <- olyan utasítás, amit a fordító fordítás előtt értelmez és végrehajt (magyarul: előfeldolgozó).
Az include-ot a PAWN a C-ből örökölte meg, röviden: \"ennek a fájlnak a tartalmát illeszd be ide\". Tehát, amit az include-dal behivatkozunk, annak a forrásfájlnak a tartalmát a fordító az include helyére szépen bedobja.
 
Mi ennek a jelentősége?
Sorrendiség. Nem mindegy, hogy bizonyos modulok milyen sorrendben vannak beágyazva. Ha egy modul hivatkozik valamire egy másikból, akkor az utóbbit nyilván előbb be kell ágyazni, mint az előbbit. Viszont pont ezért mondtam, hogy ha egy modul függ a másiktól, akkor a beágyazást az adott modul végezze inkább.y_hooks
 
Ez az include a YSI része.
Célja: megfelelően hook-olni a callback-eket, intuitív szintaxissal, minél kevesebb \"fejfájást\" okozva.
 
Mire jó?
Arra, amit korábban említettem: többször szerepelhet a kódban egy callback. Így a modulokban egyenként szerepelhet pl. az OnPlayerConnect, minden probléma nélkül. Nem kell ALS guard-okat definiálni (ezek amúgy is boiler plate kódot eredményeznek, erről esetleg később egy másik leírásban).
 
Használata:
Minden egyes modulba szépen beágyazzok a y_hooks-t, majd a callback-eket a public kulcsszó helyett a hook kulcsszóval látjuk el.
Példa:
 

/*==============================================================================
Model selection menu
==============================================================================*/
#include <YSI\\y_hooks>
static stock skinList;
/*==============================================================================
Hooks
==============================================================================*/
hook OnGameModeInit() {
skinList = LoadModelSelectionMenu(\"MidnightRPG/Menus/skins.txt\");
}
hook OnDialogResponse(playerid, dialogid, response, listitem, inputtext[]) {
if(dialogid == DIALOG_FIRST) {
   ShowModelSelectionMenu(playerid, skinList, \"Select Skin\");
}
return 1;
}

 

Ezek után, ezek a hook-ok a beágyazás sorrendjében fognak lefutni, mikor az eredeti meghívódik. Így, a projektben egyszer szerepelhet public kulcsszóval is egy adott callback és az azt fogja jelenteni, hogy az fusson le legelőször.A static és a stock
 
Nem hiába szerepelnek a PAWN-ban ezek a kulcsszavak. A moduláris projektek különös hasznát veszik.
A static jelentése: csak a saját fájljában látható.
A stock jelentése: amíg nincs hivatkozva az ezzel ellátott metódus vagy változó, addig az interpreter szimplán \"hozzá sem köti\" a lefordított script-hez, egyszerűen csak lehagyja. Amint használjuk, be lesz kötve, viszont ha nincs többet használva, akkor megint csak kikerül a programból.
 
A static haszna: meggátolni másokat, hogy rosszul használják a kódodat. Az OOP egységbezárás alapelve működik itt: csak azokat a részleteket jelenítsük meg a külvilágnak, amelyek feltétlenül szükségesek. Magyarul: ha valamit más fájlban/modulban nem használsz, az legyen static. Ezzel már kevesebb lehetőséget biztosítasz másoknak arra, hogy hibákba fussanak bele, ha a kódodat használják.
A stock haszna: amíg valami nincs használva, addig ne foglalja feleslegesen a helyet a memóriában. Valamint, ha már nincs rá szükség, akkor szabaduljon föl. Érdemes minden modulban a metódusokat ezzel ellátni. Ha viszont biztosra tudod, hogy valami folyamatosan használva lesz, akkor ott el kell hagyni.
 
Kiegészítés
 
Mivel ez a módszer több fájlos projekteket eredményez, ezért nem ajánlom a pawno-t a szerkesztéshez.
Nem szeretnék most részletesen bele menni abba, hogy hogyan kell más környezeteket beállítani a PAWN-hoz, rengeteg leírás található neten róla, itt csak megemlítek két példát, amiket én is használok: Sublime Text 3 és Visual Studio Code.
Mindenkinek \"szája íze\", de én ezeket találtam erre a célra a legkényelmesebbnek.
Köszönet Naretev-nek, hogy szólt.Köszönöm a figyelmet.

   
      Hiányoltam is annó, hogy nincs Magyar nyelvű leírás moduláris scripteléshez, viszont szerencsére angol thread-ek kisegítettek.
   
   
      Hasznos lehet azoknak, akik még foglalkoznak ezzel illetve még nem tapasztalták ezt meg. Szerinem még annyival bővíthetnéd, hogy a y_hooks menetét levezeted, nem teljes rendszert, hanem csak az alap megértést segítené. Nekem például addig nem is tetszett ez az egész amíg nem tudtam, hogy működnek a hook-ok. Esetleg még a különböző fejlesztői felületeket amelyekkel átlátható a modular, azoknak a beállítása stb., nem kapcsolódik szorosan hozzá, viszont nem ajánlott pawno-ba scriptelni így. Ajánlott például a Sublime Text meg hasonló IDE programok.
   
   
      De összefoglalva nagyon hasznos leírás lett!
   

Ja igen, köszi, hogy szólsz, ezt a részét kifelejtettem.
Az IDE-kről nem nagyon akartam itt beszélni, de akkor hozzá teszem a leíráshoz, hogy erre a pawno teljesen képtelen.
A y_hooks-ról még később írok, most ezt gyorsan be kellett fejeznem.