Paraméterek

Természetesen a függvény1-nek nem sok értelme van, de például készítsünk egy olyan függvényt, ami kiszámítja egy kör területét. Nem egy konkrét körére gondolok, hanem olyan függvényt szeretnék, amibe paraméterként átadhatom az aktuális kör sugarát, és ebből számítja a területet:

Ez a formátum hasonlatos a hagyományos programnyelvek függvénydefinícióihoz, de a függvényem meghívásának módja kicsit más. Nem kell zárójelet használni, és ha több paraméterem lenne, azok közé nem kell vessző, mert ugye a PowerShellben a vessző a tömb elemeinek szétválasztására való!

Paraméterinicializálás

Nézzünk egy újabb függvényt, egy négyszög területét akarom kiszámoltatni:

Mi van akkor, ha egy négyzetnek a területét akarom kiszámoltatni, aminek nincs külön x és y oldala, csak x:

Hát ez nem sikerült, hiszen a függvényem két paramétert várt, az $y nem kapott értéket, így a szorzat értéke 0 lett. Lehetne persze a függvényen belül egy IF feltétellel megvizsgálni, hogy vajon a $y kapott-e értéket, és ha nem, akkor x²-et számolni. Ennél egyszerűbben is lehet ezt elérni a paraméterek inicializálásával:

Itt a [15]-ös sorban az $y változónak átadom az $x értékét. Ez az értékadás azonban csak akkor jut érvényre, ha a függvény meghívásakor én nem adok neki külön értéket, azaz továbbra is működik a téglalap területének kiszámítása is:

A paramétereknek nem csak másik változó adhat alapértéket, hanem tehetünk oda egy konstanst is:

Típusos paraméterek

Hasonlóan, ahogy a változóknál is definiálhatunk típust, a függvények paramétereinél is jelezhetem, hogy milyen típusú adatot várok. Ez a függvény hibás működésének lehetőségét csökkentheti.

Nézzük a körterület-számoló függvényemet, mit tesz, ha szövegként adok be neki sugarat:

Elég érdekesen alakul ez a geometria a PowerShellben! De eddigi ismereteink alapján rájöhetünk, hogy mi történt. Ugye a függvényünk belsejében ez található:

Az első $sugár a PowerShell szabályai szerint lehet „2” (szövegként). A második már nem, viszont működik az automatikus típuskonverzió, tehát csinál belőle 2-t (szám). Idáig kapunk „22”-t, azaz az első sztringemet („2”) kétszer egymás mellett. Majd jön a PI, ugyan az nem egész, de itt is jön a típuskonverzió, lesz belőle 3, azaz immár a „22”-t rakja egymás mellé háromszor, így lesz belőle „222222”.

Na, ezt nem szeretnénk, ezért tegyük típusossá a sugarat:

Itt már helyes irányba tereltük a PowerShell típuskonverziós automatizmusát, rögtön a paraméterátadásnál konvertálja a szöveges 2-t számmá, innentől már nincs félreértés.

Hibajelzés

Az előző körterület függvényemnél, ha a paraméter nem konvertálható [double] típussá, akkor hibát kapunk, anélkül, hogy mi ezt leprogramoztuk volna:

Viszont elképzelhető olyan paraméterérték is, ami bár nem okoz problémát közvetlenül se a típusos paraméternek, se a függvény belsejének, de mi mégis szeretnénk hibaként kezelni. A körterület példámnál tekintsük hibának, ha valaki negatív számot ad meg sugárnak. A fentihez hasonló formátumú (piros betűk) hibaüzenetet írattathatunk ki a throw  kulcsszó segítségével:

De nem csak ilyen esetben lehet szükség hibakezelésre, hanem akkor is, ha valaki nem ad meg paramétert. Egy paraméterkötelező vagy opcionális voltát majd a 2.5 Fejlett függvények – script cmdletek fejezetben, a fejlett függvények függvénydefiníciójában tudjuk majd igazán profi módon beállítani, de most itt egyszerűen a throw segítségével végezzük ezt el:

Látszik, hogy már az értékadásnál használhatjuk a hibajelzést, mint alapértéket. Ha nem ad a felhasználó paraméterként értéket, akkor végrehajtódik a hibakezelés, viszont ha ad értéket, akkor természetesen erre nem kerül sor.

Változó számú paraméter

Előfordulhat olyan is, hogy nem tudjuk előre, hogy hány paraméterünk lesz egy függvényben. Például szeretnénk kiszámolni tetszőleges darabszámú sztring hosszának az átlagát. Ilyenkor dilemmába kerülhetünk, hiszen hány paramétert soroljunk fel? Hogyan inicializáljuk ezeket?

Szerencsére nem kell ezen töprengenünk, mert a PowerShell készít automatikusan egy $args  nevű változót, amely tartalmazza a függvénynek átadott valamennyi olyan paramétert, amelyet úgy adunk át, hogy nem névvel hivatkozunk rájuk:

Az átlaghossz függvényemnek ezek alapján nincs explicit paramétere, azaz névvel nem is lehet hivatkozni a paramétereire, viszont implicit módon az $args tömbön keresztül természetesen megkapja mindazt a paramétert, amelyet átadunk neki. Ebben az esetben azonban nehezebben tudjuk kézben tartani a paraméterek típusát, ezt is majd a fejlett függvényekkel tudjuk elvégezni ( 2.5 Fejlett függvények – script cmdletek fejezet).

Mi van az $args változóval, ha vannak explicit paramétereink is? Nézzünk erre egy példát:

Láthatjuk, hogy úgy működik a PowerShell, ahogy vártuk, a nevesített paraméterek nem kerülnek bele az $args tömbbe, így a fenti függvényemben egyetlen argumentum sem lett duplán kiírva.

Hivatkozás paraméterekre

Eddig az összes függvénypéldámban a függvények meghívásakor a paraméterátadás pozíció alapján történt. Ez egyszerűen azt jelenti, hogy az első paraméter átadódik a függvénydefiníció paraméterei között felsorolt első változónak, a második paraméter a második változónak és így tovább. Ha több paramétert adunk át, mint amennyit a függvény definíciójában felsoroltunk, akkor ezek az extra paraméterek az $args változóba kerülnek bele.

Mi van akkor, ha egy függvénynek opcionális paramétere is van, és nem akarok neki értéket adni? Ezt eggyel több szóköz leütésével jelezzem? Alakítsuk át ennek szemléltetésére az előző „mondatgenerátor” függvényemet:

Itt három explicit paramétert fogad a függvény. Ha tényleg három paraméterrel hívom meg, akkor minden paraméter a helye alapján kerül a megfelelő helyre. Ha a második paramétert ki szeretném hagyni, akkor ezt hiába akarom jelezni eggyel több szóközzel ([50]-es sor), ez természetesen a PowerShell parancsértelmezőjét nem hatja meg, így más módszerhez kell folyamodnom, ez pedig a név szerinti paraméterátadás:

Így már tényleg minden a helyére került. A név szerinti paraméterátadásnál is számos gépelést segítő lehetőséget biztosít számunkra a PowerShell:

Az [56]-os sorban látható, hogy a nevekre olyan röviden elég hivatkozni, ami még egyértelművé teszi, hogy melyik paraméterre is gondolunk. Az [57]-es sorban meg az látható, hogy a PowerShell elfogadja a sok egyéb parancssori környezetben megszokott paraméterátadási szintaxist is, azaz hogy kettőspontot teszünk a paraméternév után.

A hely szerinti és pozíció szerinti paraméterhivatkozást vegyíthetjük is:

Itt a szabály az, hogy a PowerShell először kiveszi a függvényhívásból a nevesített paramétereket, majd hely szerint feltölti a többi explicit paramétert, és ha még mindig marad paraméter, azt berakja az $args változóba.

Paraméterátadás változó szétpasszírozásával (splat operátor)

Nézzük, hogy hogyan lehet még paramétereket átadni. Vegyük példa gyanánt az előző mondatgenerátor függvényt. Egy változóban vannak tömbként az egyes paraméterek, vajon hogyan lehet a tömb elemeit átadni rendre az egyes paraméterek gyanánt?

A [2]-es sorban látható a paramétereke tartalmazó tömböm, de ha ezt adom át a mondatgenerátoromnak, akkor nem azt kapom, amit szerettem volna. Az átadott változó mint egy egység adódott át az első, „eleje” paraméterként, és a többi paraméternek nem jutott érték.

A PowerShell 2.0-ban bevezettek egy új operátort, a „szétpasszírozás” operátorát (angolul splatting – szétfröccsenés) , amit pont arra találtak ki, hogy egy tömbváltozó elemeit adja át rendre a függvény vagy cmdlet paramétereiként:

Ez pont azt az eredményt adta, amit szerettem volna. Enélkül elég bonyolult lett volna ezt a fajta paraméterátadást megoldani.

Nézzük, hogy hogyan lehet név alapján átadni a paramétereket a szétpasszírozás operátorával. Ilyenkor a változóba hashtáblát kell tenni:

A fenti példában láthatjuk, hogy a paraméterek nem a sorrendjük, hanem a nevük alapján lettek átadva.

Kapcsoló paraméter ([switch])

Sok függvénynél előfordul olyan paraméter, amelynek csak két állapota van: szerepeltetjük a paramétert vagy sem. Ez nagyon hasonlít a [bool] adattípushoz, de feleslegesen sokat kellene gépelni, ha tényleg [bool]-t használnánk:

Sokkal egyszerűbb lenne csak ennyit írni:

Erre találták ki a [switch]  adattípust, amelyet elsődlegesen pont ilyen paraméterek esetében használunk.

A fenti „lámpa” függvényemet, ha kapcsoló nélkül használom, akkor „sötétet” jelez (az IF ELSE ága), ha van kapcsoló, akkor „világos”. Azaz, ha szerepel a paraméterek között a kapcsoló, akkor változójának értéke $true lesz, ha nem szerepel a kapcsoló, akkor változójának értéke $false lesz.

Paraméter-definíció a függvénytörzsben (param)

Ha valaki olyan programozói háttérrel rendelkezik, ahol megszokta, hogy a függvénydefinícióknál van egy külön deklarációs rész, akkor használhatják a param  kulcsszót a függvény paramétereinek deklarálásához:

Itt a get-random függvényem neve után nem szerepel semmilyen paraméter, hanem beköltöztettem a függvénytörzsbe, itt viszont kötelezően egy param kulcsszóval kell jelezni a paramétereket. Ez akkor is hasznos lehet, ha bonyolultabb kifejezésekkel adok kezdőértéket a paramétereimnek, mert ezzel a külön deklarációs résszel sokkal olvashatóbb lesz a függvényem.

Ennek paraméterezési lehetőségnek egyébként nem is itt, hanem majd a szrkipteknél lesz még inkább jelentősége.

Paraméterek, változók ellenőrzése (validálás)

Természetesen a paraméterek ellenőrzése akkor a legegyszerűbb, ha eleve csak a kívánalmainknak megfelelő értékeket lehetne átadni. A típus megfelelőségének vizsgálatához már láthattuk, egyszerűen csak egy típusjelölőt kell a paraméter neve előtt szerepeltetni. De vajon milyen lehetőségünk van, ha még további megszorításokat szeretnénk tenni?

Ennek egyik lehetősége, hogy a függvényünk törzsében saját programkóddal ellenőrizzük az érték helyességét. Például nézzünk a korábban már látott körterület kiszámító függvényt:

Itt én ellenőrzöm, hogy csak pozitív számot lehessen megadni sugárnak. A .NET keretrendszerben azonban vannak kifejezetten ilyen jellegű, paraméterellenőrzésre szolgáló osztályok is. Ilyen szabályokat hozzá is rendelhetünk változókhoz, erre szolgál a változók tulajdonságai között az Attributes tulajdonság:

Alaphelyzetben ez a tulajdonság üres, vajon hogyan és mivel lehet feltölteni? Nézzük meg, hogy milyen metódusai vannak ennek az attribútumnak:

Tehát van neki Add metódusa, ezzel lehet ellenőrzési objektumokat hozzáadni ehhez az attribútumhoz. A PowerShell MSDN weboldalán:

( http://msdn.microsoft.com/en‑us/library/system.management.automation.validateargumentsattribute(VS.85).aspx) )

  És a Reflector programmal a System.Management.Automation névtérbe beásva ezeket az ellenőrzési osztályokat lehet megtalálni:

Nézzünk ezek használatára néhány példát. Az elsőben szeretnék olyan változót használni, amely csak 1 és 5 darab karakter közötti hosszúságú szöveget fogad el:

A [87]-es sorban definiálom a VaildateLengthAttribute osztály egy objektumát. Majd létrehozok egy $szó nevű változót „rövid” tartalommal. Ennek a változónak az Attributes tulajdonságához hozzáadom az előbb létrehozott ellenőrzési objektumot. A [90]-es sorban a változómnak egy 5 karakternél hosszabb értéket szeretnék adni, de erre hibát kaptam.

Nézzünk egy hasonló példát az üresség vizsgálatára:

Ha egy ilyen ellenőrzési attribútummal látunk el egy változót, akkor az megmutatkozik a változó tulajdonságai között is:

Ezekből az ellenőrzési objektumokból egyszerre többet is lehet egy változóhoz rendelni.

Sajnos ezen ellenőrzési objektumok felhasználásának egyik fő nehézsége az, hogy ahhoz, hogy ilyen szabályt egy változóhoz rendelhessük, ahhoz addigra már a változónak olyan értékkel kell rendelkeznie, amelyre teljesül az ellenőrzési feltétel. Azaz, ha például egy NotNull típusú ellenőrzést szeretnénk hozzárendelni egy változóhoz, addigra már valamilyen értékkel kell rendelkeznie a változónak, különben nem engedi a szabályt hozzárendelni. Így a függvények paramétereinél történő felhasználásuk kicsit körülményes:

Azaz a függvény törzsében létrehozok egy tesztelési célokat szolgáló $pteszt változót, ami kielégíti azt a feltételt, hogy nem üres az értéke, és ez a változó hordozza az ellenőrzési objektumot is. A függvény paraméterének ellenőrzésére a $p változó értékét átadom ennek a tesztelési célra létrehozott változónak. Amikor a függvényemet paraméter nélkül hívtam meg, akkor hibát kaptam. Itt igazából csak annyit spóroltam, hogy nem nekem kell lekezelni és kiírni a hibát, ezt a PowerShell helyettem elvégezte.

Az igazi, profi paraméterellenőrzést a PowerShell 2.0 a fejlett függvényeknél már lehetővé teszi, erről a 2.5   Fejlett függvények – script cmdletek fejezetben lesz szó.

Word To HTML Converter