INFIMUM 2024

Az INFIMUM 2024 Konferenciát a Neumann János Egyetem GAMF Műszaki és Informatikai Karán került megrendezésre, Kecskeméten, 2024. június 14-15-én.

A konferencia céljai

A rendezvény elsődleges célja annak elősegítése, hogy a felsőoktatási intézmények oktatói és kutatói az informatika, a fizika, a matematika és a logisztika korszerű és hatékony oktatásáról és tudományos eredményeiről előadások, poszter-bemutatók és személyes találkozás révén tapasztalatot cserélhessenek, valamint kapcsolatot építhessenek.

A konferencia tervezett főbb témakörei

  • a korszerű matematika-, fizika-, logisztika- és informatikatanítás és tanulás új útjai és távlatai, oktatásfejlesztési tapasztalatai,
  • a felsőoktatás alapozó tárgyainak oktatás-módszertani problémái,
  • mesterképzésbe való bekapcsolódás, a duális képzés gondjai és tapasztalatai,
  • matematika, fizika, informatika, logisztika tudományos eredményei,
  • új és innovatív kutatási irányok, problémák és gyakorlati alkalmazások bemutatása a fenti tudományterületeken.

A konferencia programja

A letölthető absztraktkötet tartalmazza a szervezőbizottság által összeállított programot. Pénteken került sor a szakmai programra. Szombaton zajlott a Strázsa túra, utána az EB meccset lehetett megnézni a GAMF udvarán, végül borkóstolóval zárul a rendezvény.

A konferenciára 37 résztvevő regisztrált és tartott plenáris vagy szekcióelőadást. A Matematika oktatása szekció 18 előadásból, az Informatika szekció és a Fizika szekció pedig egyaránt 5-5 előadásból állt.

Az absztraktok ISBN 978-615-6435-83-5 számmal rendelkező absztraktkötetben jelentek meg. Lehetőség volt hosszabb, 1-2 oldalas összefoglalók megjelentetésére is. A szakmai cikkek a Gradus lektorált, online folyóiratba egyénileg nyújthatók be magyar vagy angol nyelven, maximum 10 oldal terjedelemben (utólag is). A folyóirat (ISSN 2064-8014) eredeti publikációkat közöl számos témakörben, beleértve a természettudományok minden területét, mindenféle műszaki tudományt, számítástechnikát, kertészetet, környezetmérnökséget, pedagógiát, didaktikát és közgazdaságtant. A számítástechnika és a matematika elméleti és alkalmazott területeit is befogadja. A folyóirat csak kutatási cikkeket közöl, és minden cikk az esettanulmányok, kísérletek, vagy a gyakorlatban már alkalmazott megközelítésekkel való szisztematikus összehasonlítások révén előrehaladó ötletek gyakorlati alkalmazását tárgyalja.

Részt vettem a konferencián

2024-ben egy szakmai előadást tartottam 20 percben Letöltés szimuláció – esettanulmány Java nyelven címmel. Erről a témáról szól korábbi blog bejegyzésem, lásd: Letöltés szimuláció.

Szakmai előadásom összefoglalója

A szerző letöltési folyamatot szimulál. A paraméterek rugalmasan beállíthatóak. Előre beállított mennyiségű adatokat, párhuzamos szálakon/folyamatokon keresztül tölt le, miközben méri az eltelt időt. A folyamatok állapota lehet inaktív, aktív és befejezett. Az aktív folyamatok esetében megjelenő százalék fejezi ki, hogy a folyamat hol tart a rá jutó részfeladat végrehajtásával. Összesített formában követhető a hiányzó és a letöltött adat mennyisége MB-onként és százalékosan is. A folyamat szimulációjához objektumorientált szemléletű, grafikus felhasználói felületű Java kliensprogram készült, egyszerű GUI komponensekkel. Az előadás/cikk bemutatja feladatspecifikációt, a tervezés és megvalósítás lépéseit, ismertet tesztelési és továbbfejlesztési lehetőségeket. A szimuláció megközelítése elvi/általános szintű. Az esettanulmány konkrét adatokkal paraméterezett. Kitér az elosztott alkalmazások különböző felépítési, tervezési, megvalósíthatósági lehetőségeire.

A konferencia a korábbi MAFIOK konferenciasorozat hagyományait követi. Ezen 2023-ban is részt vettünk és beszámoltunk róla az it-tanfolyam.hu szakmai blogban, lásd: MAFIOK 2023. Ott korábbi, MAFIOK-os publikációinkat is felsoroltuk.

A Java SE szoftverfejlesztő tanfolyamunkon, a szakmai modul Objektumorientált programozás témakörét követő 29-36. óra Grafikus felhasználói felület alkalmain már tudunk egyszerűbb szimulációs programot tervezni, kódolni, tesztelni. A Java EE szoftverfejlesztő tanfolyamunkon, a szakmai modul 5-8. óra Szálkezelés, párhuzamosság alkalommal többféle elosztott stratégiát ismertetünk, és a 17-24. óra Socket és RMI alapú kommunikáció alkalommal pedig megvalósíthatjuk többféle protokoll szerint a hálózati kapcsolatot, letöltést/feltöltést.

A TIOBE Java kódolási szabályokról

A TIOBE Java Coding Standard aktuális verziója a 3.10. Java programozási nyelven írt/karbantartott forráskódra vonatkozó szabályokat/ajánlásokat tartalmaz. Célja: a kódolási hibák elkerülése, az elavult vagy implementációfüggő nyelvi funkciók használatának elkerülése, illetve a következetes, konzisztens kódolási stílus kialakítása.

A TIOBE Java Coding Standard dokumentáció szerkezete

A TIOBE Java kódolási szabályok 19 kategóriába soroltak, 1-8-ig szint alapján csoportosítottak, továbbá ellenőrzött és nem ellenőrzött állapotban vannak. Az alábbi Sankey-diagram segít áttekinteni a dokumentációt:

A TIOBE Java kódolási szabályok kategóriánként

A továbbiakban néhány kategóriából emeltem ki néhány szabályt/ajánlást – amiket fontosabbnak tartok.

  • 34 db alapszabály van. Ezek olyan jó gyakorlatok, amiket mindenkinek követnie kell. Nem írunk üres if, switchutasításokat. Nem írunk üres while, try, finally, synchronized, static blokkokat. Nem írunk tesztelős ciklust számlálósként, így: for (;true;). Nem módosítjuk a for ciklus változóját a ciklusmagban. Ne használjunk felesleges public, static, finalmódosítókat és (eljárásokban) return utasítást.
  • 8 db kódmérethez kötődő szabály van. Ne írjunk hosszú, sok utasításból álló metódusokat. Ne használjunk túl sok paramétert metódusok, konstruktorok esetén. Ügyeljünk a forráskód ciklomatikus komplexitására, amely a tesztelési nehézségek egyik mutatószáma. Ne tervezzünk túl sok publikus metódust és mezőt/tulajdonságot egy osztályba. A limitek a fentiek sorrendjében: 100 utasítás, 10 paraméter, 1000 kódsor, 10-es komplexitású metódus, 45 metódus, 15 mező/tulajdonság.
  • 4 db kommentekre vonatkozó szabály van. Ezek forrásfájlokra, annotációkra, TODO-kra és speciális JavaDoc-ra érvényesek.
  • 4 db ellentmondásos/vitatott szabály van. Például ne importáljunk a sun.* csomagokat, illetve ne használjunk felesleges kerek zárójelpárokat, értékadással egybeépített összehasonlítást egy feltételben.
  • 42 db tervezési szabály van. Függvényben lévő if-then-else utasításben lévő két return helyett adjuk vissza közvetlenül a logikai kifejezés értékét. Logikai kifejezésekben ne legyenek felesleges összehasonlítások. A switch utasításban hiányzó break utasítás tervezési hibára utal (bár nem szintaktikai követelmény, hogy legyen). A switch utasításban kellene default ágnak lennie (és egyben álljon az utolsó helyen). Ne definiáljuk felül egy metódus bejövő paraméterét. Az equals() összehasonlító metódust ne hívjuk meg null paraméterrel. Ne használjunk idempotens műveleteket, például ne adjunk értékül egy változót/objektumot saját magának. A SimpleDateFormat osztály és String.toLowerCase()/toUpperCase() metódusok használata során mindig állítsuk be a Locale objektumot. A synchronized kulcsszót ne kívülről, metódusra, hanem belülről, blokkban használjuk. Konstanst ne inicializáljunk null-ként. Kollekciók esetén a size()==0 vagy size()!=0 helyett hívjuk meg az isEmpty() függvényt. Az instanceof operátor használata előtt nem kell ellenőrizni, hogy az objektum nem null. A megnyitott erőforrásokat mindig zárjuk le a close() metódussal.
  • 7 db véglegesítéshez kötődő szabály van. Ha írunk finalize() metódust, akkor az ne legyen üres és ne legyen paramétere sem. Inkább ne írjunk finalize() metódust, mert nincs garancia arra, hogy végrehajtódik (illetve szintén nem tudjuk, hogy mikor fut le).
  • 5 db importáláshoz kapcsolódó szabály van. Importáljunk pontosan. Ne importáljunk a java.lang csomagból (mert ez alapértelmezett). Ne importáljunk többszörösen. Ne maradjanak nem használt importok a végleges forráskódban.
  • 4 db logolásra vonatkozó szabály van. Egy osztályban egyetlen Logger legyen. A System.(out|err).print() metódus és kivételkezelés során printStackTrace() helyett inkább logoljunk.
  • 1 db szabály van a többszálúsághoz kötődően. Példányváltozó közvetlenül elérhető több szál számára. Az ehhez való megosztott hozzáférés szabályozása, szinkronizálása nehéz, ezért inkább hozzunk létre belőle annyi példányt, ahány szálon fut a program.
  • 10 db elnevezésre vonatkozó szabály van. Kerüljük a hosszú változóneveket és a rövid metódusneveket. Ne használjunk $ jelet a változók, metódusok, osztályok, interfészek elnevezése során. Ne használjunk a Foo osztályban Foo() metódusnevet (mert ez a konstruktor), és foo változónevet sem. Minden osztály és interfész tartozzon csomagba.
  • 8 db optimizáláshoz kötődő szabály van. Ha egy változó nem módosul és csak egyszer kap értéket, akkor legyen konstans. Ha tömbből generikus listát készítünk, akkor használjuk az Arrays.asList() metódust (ahelyett, hogy ciklust írunk az adatszerkezet konstrukciójához). Csomagolóosztályt csak szükség esetén alkalmazzunk (mert autoboxing van). A Calendar helyett használjunk inkább „olcsóbb” osztályokat.
  • 2 db kódbiztonsági szabály van. Ne égessünk a forráskódba kriptográfiához kötődő adatokat (kód, jelszó, hash). Ezeket a kulcsokat külső fájlokban tároljuk.
  • 11 db szabály vonatkozik a kötelező kivételkezelésre. Nem szabad catch (Throwable t) ágat használni, mert memóriaproblémát okozhat. Konstruktor/metódus ne dobjon általános kivételt ( Exception) – helyette dobjon szükség esetén speciálisabb/leszármazott kivételt. Ne kapjunk el általános kivételt; specializáljuk ezt is. Kivételkezeléssel ne valósítsunk meg vezérlést. Ne kapjunk el NullPointerException-t; inkább szüntessük meg a keletkezésének okát. Ha lehet, akkor a try-catch-finally blokk helyett alkalmazzunk erőforrás-kezelő kivételkezelést.
  • 14 db szabály vonatkozik a szövegkezelő String és StringBuffer osztályok használatára. Közvetlenül inicializáljuk a String típusú objektumokat, felesleges hozzá konstruktort használni. Csak akkor használjuk a toString() metódust, amikor feltételül szükséges. Összehasonlításnál az equalsIgnoreCase() metódus gyorsabb a toUpperCase/toLowerCase().equals() metódusoknál. Láncoljuk az append() függvényeket, amikor csak lehet. Ha nem szükséges, akkor ne használjuk a String.valueOf() függvényt. String objektumok összehasonlítát az equals() metódussal végezzük el.
  • 3 db típusrezolúciós szabály van. Használjunk ArrayList list=new ArrayList() helyett List list=new ArrayList() deklarációt (értékadás bal oldalán statikus típus (interfész), jobb oldalán dinamikus típus (implementáció)). Tömb létrehozásához használjunk int[] x=new int[] {1, 2, 3} helyett int[] x={1, 2, 3} inicializáló blokkot. Generikus lista létrehozásánál használjunk List<String> strings=new ArrayList<String>() dupla gyémánt operátor helyett csak egyet, így: List<String> strings=new ArrayList<>().
  • 5 db nem használt forráskódokra vonatkozó szabály van. Ezek privát változókra, lokális változókra, privát metódusokra, felesleges értékadásokra, üres utasításokra érvényesek.

Nem tértem ki a 2 db klónozáshoz, 2 db csatoláshoz (importáláshoz), az 1 db stílushoz kötődő szabályra. Továbbá van 5 db már elavult, tervezésre vonatkozó szabály.

A fentieket érdemes megfogadni, betartani, céges környezetben megfelelően kiegészíteni, testre szabni. A teljes angol nyelvű dokumentáció elérhető: Coding Standard Viewer. A weboldalon érdemes a Java programozási nyelvre vonatkozó szabályokat, ajánlásokat összehasonlítani más nyelvekre vonatkozó szabályokkal, ajánlásokkal. Összesen 8 programozási nyelvhez találhatók szabályok, ajánlások. Elérhetők a forráskód minőségét, karbantarthatóságát kifejező TQI szempontok, paraméterek dokumentációi is: TIOBE Quality Indicator (TQI), valamint a TIOBE TÜViT Trusted Product Maintainability ISO/IEC 25010 Quality Model. Egy szint felett már ezeket is figyelembe kell venni.

Korábbi blog bejegyzésünk a fenti saját készítésű ábra, grafikon elkészítéséről: Sankey-diagram készítése. Érdemes a hozzászólásokat is tanulmányozni a jó példákért.

Egy matematika érettségi feladat megoldása programozással 2024

érettségi logó

érettségi logóA 2024-es középszintű matematika érettségi feladatsorból az 12. feladata inspirált arra, hogy elkészítsem a grafikus ábrázolását Java nyelven. A korábbi Kígyókocka grafikus felületen esettanulmány kiváló alapot, „keretrendszert” adott a továbbfejlesztésre. Érdekes belegondolni, hogy mennyire más lehetne a problémamegoldás, ha programozhatnánk a matematika érettségi vizsgán. A teljes feladatsor letölthető az oktatas.hu-ról.

12. feladat

Egy piros, egy fekete és egy fehér szabályos dobókockával egyszerre dobunk. Határozza meg annak a valószínűségét, hogy a dobás eredménye három különböző szám lesz! Megoldását részletezze!

1. megoldás

A kedvező /összes eset száma ad választ a kérdésre. Az egymásba ágyazott ciklusok – i-j-k számhármasokként – előállítják az összes esetet. Ezek száma 216, rendre: 1-1-1, 1-1-2, …, 1-1-6, 1-2-1, …, 6-6-5, 6-6-6-ig. A összes eset között megtalálhatók a kedvező esetek. Ezek száma 120, rendre: 1-2-3, 1-2-4, 1-2-5, 1-2-6, 1-3-2, 1-3-4, 1-3-5, 1-3-6, 1-4-2, 1-4-3, 1-4-5, 1-4-6, 1-5-2, 1-5-3, 1-5-4, 1-5-6, 1-6-2, 1-6-3, 1-6-4, 1-6-5, 2-1-3, 2-1-4, 2-1-5, 2-1-6, 2-3-1, 2-3-4, 2-3-5, 2-3-6, 2-4-1, 2-4-3, 2-4-5, 2-4-6, 2-5-1, 2-5-3, 2-5-4, 2-5-6, 2-6-1, 2-6-3, 2-6-4, 2-6-5, 3-1-2, 3-1-4, 3-1-5, 3-1-6, 3-2-1, 3-2-4, 3-2-5, 3-2-6, 3-4-1, 3-4-2, 3-4-5, 3-4-6, 3-5-1, 3-5-2, 3-5-4, 3-5-6, 3-6-1, 3-6-2, 3-6-4, 3-6-5, 4-1-2, 4-1-3, 4-1-5, 4-1-6, 4-2-1, 4-2-3, 4-2-5, 4-2-6, 4-3-1, 4-3-2, 4-3-5, 4-3-6, 4-5-1, 4-5-2, 4-5-3, 4-5-6, 4-6-1, 4-6-2, 4-6-3, 4-6-5, 5-1-2, 5-1-3, 5-1-4, 5-1-6, 5-2-1, 5-2-3, 5-2-4, 5-2-6, 5-3-1, 5-3-2, 5-3-4, 5-3-6, 5-4-1, 5-4-2, 5-4-3, 5-4-6, 5-6-1, 5-6-2, 5-6-3, 5-6-4, 6-1-2, 6-1-3, 6-1-4, 6-1-5, 6-2-1, 6-2-3, 6-2-4, 6-2-5, 6-3-1, 6-3-2, 6-3-4, 6-3-5, 6-4-1, 6-4-2, 6-4-3, 6-4-5, 6-5-1, 6-5-2, 6-5-3, 6-5-4.

A megszámolás programozási tétel előállítja a szükséges változókat, amik hányadosa megadja a szükséges p valószínűséget és ezt a program ki is írja a konzolra: A keresett valószínűség: 0.5555555555555556. Az esetek/lehetőségek felsorolása egyben a megoldás részletezése. A megszámoláshoz használt sokféle feltétel természetesen átfogalmazható lenne. Az egyszerűsítés többféleképpen is elvégezhető, többek között a De Morgan-azonosságok alkalmazásával.

2. megoldás

A korábbi JavaFX alapon megvalósított program módosításával könnyen állítható a megoldás grafikus/vizuális reprezentációja. Íme egy képernyőkép az elkészült program felhasználói felületéről:

A 3 db dobókockával kapott számhármasok 3D-ben, térbeli pontként jelennek meg egy kockában. A nagy piros gömbök jelölik azt a 6 db esetet, amikor mindhárom kockadobás megegyezik. Ezek a kocka egyik testálójában találhatók. A közepes narancssárga gömbök jelölik azt a 90 db lehetőséget, amikor bármely (pontosan) két kockadobás megegyezik. Végül a kis szürke gömbök jelölik a megoldást. Ez a 120 db kimaradó eset, másképpen: amikor mindhárom kockadobás különbözik. Másféle lehetőség nincs és megvan a 216 esethez tartozó összes gömb.

A megoldás implementálása a korábbi programban szinte csak egy metódus frissítését, kiegészítését igényelte. Ez a korábbi tudatos, objektumorientált, MVC szerkezetnek köszönhető és egyben a forráskód újrafelhasználása is. A createCube() metódus az alábbiak valósítja meg a feladatot:

A belépési pont, a grafikus felület építése, a nyomógombok eseménykezelése, a geometriai transzformációk, és persze a 3D -> 2D leképezés a megjelenítés során megmaradt. A virtuális térben elhelyezett objektumok változtak (pozíció, nézőpont, anyagtulajdonság). További részletes magyarázat érhető el a Kígyókocka grafikus felületen esettanulmányban.

3. megoldás

Itt most csak ötletet szeretnék mutatni. A 2022-es 6. feladat 3-7. kombinatorikai megoldásai könnyen továbbfejleszthetők és sokféle hasznos apróság gyakorolható.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

Ajánljuk matematika érettségi feladat címkénket, mert a témában évről-évre blogolunk.

A feladat a Java SE szoftverfejlesztő tanfolyam szakmai moduljának 5-8. óra: Vezérlési szerkezetek, 9-12. óra: Metódusok, rekurzió, valamint 17-28. óra: Objektumorientált programozás alkalmaihoz kötődik.

Digitális Témahét 2024

A Digitális Témahét 2016-ban indult országos rendezvénysorozat. Fő célja, hogy a digitális eszközökkel támogatott projektpedagógia és innovatív pedagógiai módszerek terjesztésén keresztül. A program fontos törekvése, hogy a digitáliskompetencia-fejlesztés az informatikán túl kiterjedjen más tantárgyakra is. A résztvevő pedagógusok és diákok változatos és kreatív iskolai projektek keretében fejleszthetik képességeiket technológiával támogatott tanulás során. A Digitális Témahét rendezvény minden meghirdetett programja ingyenes. A 2022/2023-as tanévben is több száz hazai és külhoni intézmény regisztrált, és 100000+ tanuló vett részt egy vagy több programon, digitális projektben.

A 2023/2024-es tanévben a – sorozatban 9. – rendezvény április 5-12. között valósult meg. Kiemelt témák:

  • digitális állampolgárság;
  • a digitalizáció jelene és jövője;
  • a digitális technológia eszközei és alkalmazásai;
  • az algoritmikus gondolkodás és programozás mint az alkotás eszközei;
  • a mesterséges intelligencia jellemzői, lehetőségei, veszélyei;
  • digitális biztonság és digitális esélyteremtés.

Rendezvényünk plakátja

Az it-tanfolyam.hu 2024-ben is csatlakozott a rendezvénysorozathoz. Oktatóink meghirdettek a fenti témák inspirálta 9 programot, amelyekre 2024. április 12-én 18:00-22:00 óráig került sor.

Köszönöm oktató kollégáimnak, hogy újra örömmel csatlakoztak ehhez a rendezvényünkhöz. A résztvevőinknek is köszönjük, hogy ellátogattak hozzánk. Mindannyian jól éreztük magunkat: 40+ személyes és 30+ online résztvevőt regisztráltunk. Ismét igazán tartalmas programot állítottunk össze. Izgalmas kitekintést nyújtott a szoftveripar és a programozás területéből. Tanfolyamaink hallgatói és az érdeklődők számára is tudtunk újat mutatni. A programok közötti szünetek lehetőséget adtak a kérdésekre, az ismerkedésre. A kiállított posztereink párbeszédre ösztönözték az érdeklődőket. Idén is szívesen csatlakoztunk a rendezvénysorozathoz és szívesen emlékszünk majd vissza rá.

Dr. Sheldon Cooper kő-papír-olló-gyík-Spock játéka

Sheldon, Agymenők

Sheldon, AgymenőkDr. Sheldon Cooper karakterét nem kell bemutatni. Ha a kockáknak döntéseket kell hozniuk, akkor az Agymenők (The Big Bang Theory) sorozatban többször is előkerül a kő-papír-olló-gyík-Spock játék.

A 2. évad 8. epizódjában – amelynek címe Fogd a nőt, és fuss! (The Lizard–Spock Expansion) – ismerjük meg a játékszabályt és rögtön alkalmazásra is kerül. Raj és Sheldon megpróbálja eldönteni, hogy melyik sci-fi sorozat a (leg)jobb, illetve Howard és Sheldon így próbálnak osztozni a vacsora maradékán. Végül az 5. évad 17. epizódjában – amelynek címe Itt a festmény, hol a festmény! (The Rothman Disintegration) – újra hallhatjuk a játékszabályt. Ekkor Kripke és Sheldon egy egyetemi iroda sorsáról (kié legyen) próbál dönteni.

A kő-papír-olló-gyík-Spock játékszabály

Vajon hogyan bővül ki a klasszikus kő-papír-olló játékszabálya további két kézjel/fegyver hozzáadásával? Íme a játékszabály videóban:

Íme a játékszabály szövegesen:

Az olló elvágja a papírt,
a papír bevonja a követ,
a kő agyonüti a gyíkot,
a gyík megmarja Spockot,
Spock eltöri az ollót,
az olló lefejezi a gyíkot,
a gyík megeszi a papírt,
a papír cáfolja Spockot,
Spock feloldja a követ,
a kő eltöri az ollót.

Ugye mi sem egyszerűbb? 🙂

A játékszabálynak számos grafikus ábrázolása is van. Ezeken többnyire irányított gráf csomópontjai mutatják a kézjeleket és a nyilak iránya mutatja, hogy mi mit győz le. Például a gyíktól Spock felé mutató jelzi, hogy a gyík megmarja (azaz legyőzi) Spock-ot. Íme az egyik ábra:

A kő-papír-olló-gyík-Spock játék szimulációja Java programmal

Az objektumorientált tervezés egyik lehetősége az öröklődés beépítése. Közös pontokat, funkcionalitást keresünk. Ezeket beépítjük az ősosztályba és az utódokban kiegészítjük, testre szabjuk. Kiindulunk az alábbi absztrakt Dontes ősosztályból:

A konstans DONTES tömb (indexelhető adatszerkezet) tárolja a kézjelek/fegyverek elnevezését. Ezek közül választ véletlenszerűen a  veletlenDontes() függvény. Az eredményt ki kell tudni írni a konzolra, illetve kezelni kell a döntetlent is. Ezekért közösen felelnek a dontesEredmeny() és a kiiras() függvények. A túlterhelt metódusokként létrehozott eredmeny() függvények kezelik a 2 illetve 3 játékos esetén a döntéseket. A háromparaméteres függvény visszavezet a kétparaméteres esetre. Utóbbi metódus – mivel absztrakt – csak az utódosztályban valósul meg. Így lehetővé válik a játékszabály többféle megvalósítása.

1. megoldás

Az első megoldás során adatszerkezet nélkül valósul meg a játékszabály a  KoPapirOlloGyikSpockV1 utódosztályban:

2. megoldás

A második megoldás során a játékszabályt konstansként deklarált MATRIX szomszédsági -, csúcsmátrix, kétdimenziós tömb adatszerkezet tárolja. Ez alapján döntést tud hozni a KoPapirOlloGyikSpockV2 utódosztály.

A játékmenetért felelős vezérlés

10 lépésből álló játékmenetet hoz létre az alábbi vezérlés:

Egyben tesztelés is: igazolja, hogy azonosan működik a két különböző megoldás.

Eredmény

Mivel minden véletlenszerűen alakul a játékban, ezért az alábbi csupán egy a sokféle lehetséges kimenet közül:

A bejegyzéshez tartozó teljes forráskódot – többféle változatban is – ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java SE szoftverfejlesztő tanfolyam szakmai moduljának 5-8. óra: Vezérlő szerkezetek, 9-12. óra: Metódusok, rekurzió, 13-16- óra: Tömbök, illetve a 17-24. óra: Objektumorientált programozás 1. és 2. rész alkalmaihoz kötődik.