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

érettségi logó

érettségi logóA 2020-as emelt szintű matematika érettségi feladatsor 9. feladata inspirált arra, hogy a programozás eszköztárával oldjuk meg ezt a feladatot. Szükséges hozzá kollekció adatszerkezet és néhány programozási tétel. Érdekes belegondolni, hogy mennyire más lehetne a problémamegoldás, ha programozhatnánk a matematika érettségi vizsgán. A teljes feladatsor a megoldásokkal együtt letölthető az oktatas.hu-ról.

2018-ban és 2019-ben is kiválasztottam egy-egy matematika érettségi feladatot a középszintű feladatlapról és megoldottam Java nyelven. 2020-ban az emelt szintű feladatsornál lelkesedtem eléggé, hogy blogoljak róla.

9. feladat

Egy városban a közösségi közlekedést kizárólag vonaljeggyel lehet igénybe venni, minden utazáshoz egy vonaljegyet kell váltani. A vonaljegy ára jelenleg 300 tallér. Az utazások száma naponta átlagosan 100 ezer. Ismert az is, hogy ennek kb. 10%-ában nem váltanak jegyet (bliccelnek).
A városi közlekedési társaság vezetői hatástanulmányt készíttettek a vonaljegy árának esetleges megváltoztatásáról. A vonaljegy árát 5 talléronként lehet emelni vagy csökkenteni. A hatástanulmány szerint a vonaljegy árának 5 talléros emelése várhatóan 1000-rel csökkenti a napi utazások számát, és 1 százalékponttal növeli a jegy nélküli utazások (bliccelések) arányát. (Tehát például 310 talléros jegyár esetén naponta 98000 utazás lenne, és ennek 12%-a lenne bliccelés.) Ugyanez fordítva is igaz: a vonaljegy árának minden 5 talléros csökkentése 1000-rel növelné a napi utazások számát, és 1 százalékponttal csökkentené a bliccelések arányát. A tanulmány az alkalmazott modellben csak a 245 tallérnál drágább, de 455 tallérnál olcsóbb lehetséges jegyárakat vizsgálta.

  • a) Mekkora lenne a közlekedési társaság vonaljegyekből származó napi bevétele a hatástanulmány becslései alapján, ha 350 tallérra emelnék a vonaljegyek árát?
  • b) Hány talléros vonaljegy esetén lenne maximális a napi bevétel?

Tervezés

Értelmezve a feladatot és a feltett kérdéseket: adódik, hogy a megoldáshoz szükséges egy POJO, ami az összetartozó adatokat fogja egybe objektumként. Mivel több kell belőle, célszerű egy indexelhető adatszerkezet, például tömb vagy lista. Ékezettelen magyar elnevezéseket fogok használni. A POJO osztály neve legyen Kozlekedes és a beszédes nevű tulajdonságai legyenek a következők: vonaljegyAr, napiUtasszam, bliccelesSzazalek, napiBevetel. Mindegyik nemnegatív egész szám és belefér az int primitív típus számábrázolási tartományába.

Ha a konstruktor paraméterként átveszi az input vonaljegyAr-at, akkor abból a többi adatot egyszerű képletekkel előállíthatja. Hasznos, ha a konstruktor ellenőrzést is végez. A tanulmány az alkalmazott modellben limitálja a vonaljegy árát (250 és 450 közötti öttel osztható számként). Az öttel oszthatóság az emelés/árváltozás mértékéből adódik. Ha a vonaljegy ára nem megfelelő, akkor a konstruktor kivételt dob, amivel megakadályozza, hogy az alkalmazott modellhez nem illeszkedő tulajdonságokkal rendelkező objektum létrejöjjön.

Az output meghatározásához az a) és b) feladatban megfogalmazott kérdésekből kell kiindulni. Ezekből adódik, hogy szükséges két getter metódus a POJO-ba:  getVonaljegyAr() és getNapiBevetel(). Persze könnyen generáltatható az összes getter is, de setter nem kell. Ezeken kívül a tesztelés megkönnyítésére hasznos egy toString() metódus is, amellyel a 4 összetartozó adat hozzáférhető és megjeleníthető a konzolon.

A belépési pont és egyben a vezérlés egy másik osztályban valósul meg. Itt feltöltjük a tanulmány alkalmazott modelljének megfelelően előállított objektumokkal (memóriacímeikkel) a generikus listát, amit programozási tételekkel (kiválasztás, szélsőérték-kiválasztás) dolgozunk fel.

A POJO osztály forráskódja

A vezérlő osztály forráskódja

A main() metódus feltölti a generikus lista adatszerkezetet az alkalmazott modellben lehetséges/előforduló vonaljegyAr alapján létrehozott objektumokkal (a memóriacímükkel). A feladat9Megoldas1() metódus paraméterként átveszi a feldolgozandó listát.

Az a) feladatra a választ kiválasztás programozási tétellel kapjuk meg. A kérdés így szól: melyik az (első) olyan objektum, amelyben a vonaljegyAr egyenlő 350-nel? A ciklust követően megkapjuk, hogy az i-edik az, amelyikre igaz a feltétel. (Az nem merül fel, hogy van-e ilyen objektum, hiszen tudjuk, hogy van. Csak az a kérdés, hogy melyik az. Több sem lehet.) A  lista.get(i).getNapiBevetel() művelettel elkérjük az i-edik objektumtól a válaszadáshoz szükséges napi bevételt.

A b) feladatra a választ szélsőérték-kiválasztás programozási tétellel kapjuk meg. A kérdés így szól: melyik az (első) olyan objektum, amelyben a napiBevetel a maximális? (Mivel a lista nem üres, így létezik a legnagyobb napi bevétel. Mivel nem biztos, hogy a legnagyobb napi bevétel egyedi, ezért merül fel az első a kérdésben.) Tegyük fel, hogy a nulladik objektumra igaz a feltétel: azaz maxIndex=0. Később a ciklusban változtassuk meg a maxIndex-et, ha a feldolgozás során találunk nagyobb értéket. Szélsőérték-kiválasztásnál a kezdeti elemet nem hasonlítjuk össze saját magával (hiszen úgysem különbözne), ezért indul a for ciklus 1-ről. A ciklust követően a  lista.get(maxIndex).getVonaljegyAr() művelettel elkérhetjük a maxIndex-edik objektumtól a válaszadáshoz szükséges vonaljegy árát.

A program által felépített adatszerkezet

Ha a vezérlőben aktiváljuk a megjegyzésben szereplő kiíratást, akkor a konzolon megjelennek a main() metódusban létrehozott listában lévő objektumok adatai (amilyen viselkedést a POJO toString()-jébe programoztunk. A 246 soros szöveg görgetéssel megtekinthető.

Az eredmény

A program konzolon/szövegesen jeleníti meg a válaszokat a feltett két kérdésre:

Gondoljuk újra

Az első megoldás 41 elemű listát épít. Persze ez a lista több mindenre is jó lehet, ha több(féle) kérdést kell(ene) megválaszolni. Ezért tekinthetjük strukturális tartaléknak.

A két konkrét kérdésre azonban úgy is adhatunk választ, hogy nem építünk lista adatszerkezetet. Ez a második megoldás. A feladat9Megoldas2() metódusnak nincs paramétere és azonos eredmény ad.

Az a) feladat: egy névtelen objektumként létrehozott POJO-tól azonnal elkérhetjük a választ, ami mehet rögtön a konzolra. Ez a kiválasztás programozási tétel extrém/legjobb esete, hiszen az első objektum jó is lesz, ciklust sem kell szervezni.

A b) feladat: kiindulunk a legolcsóbb vonaljegyből és tegyük fel, hogy ekkor a legnagyobb a napi bevétel. Ciklussal léptessük a vonaljegy árát ötösével legfeljebb a legdrágábbig. Léptetés közben mindig csak azt a dinamikusan létrehozott objektumot „jegyezzük meg”, amelyiktől a röptében elkért napi bevétel a korábbihoz – az addig legnagyobbnak vélthez – képest nagyobb. Végül a megmaradó POJO-tól elkérhető a maximális napi bevételhez tartozó vonaljegy ára. Ez a szélsőérték-kiválasztás programozási tétel megvalósítása dinamikusan: kezdetben nem áll rendelkezésre az összes adat, ami alapján döntést kell hozni, ehelyett az adatokat menet/feldolgozás közben állítjuk elő és „eldobjuk” azt, ami már nem kell.

Nekem ezek a programozással való megoldások sokkal jobban tetszenek, mint az oktatas.hu-n elérhető hivatalos, matematikai megoldás, amihez differenciálszámítás is kell. Persze aki emelt szinten érettségizik matematikából, annak az sem jelenthet gondot és biztosan izgalmasnak találja.

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-24. óra: Objektumorientált programozás alkalmaihoz kötődik.

Időjárás Budapesten

Talált időjárás Widget

A Widgets constructor – OpenWeatherMap weblapon nézelődve megtetszett ez a Widget:

aktuális időjárás Budapest

Főleg az volt nagyon szimpatikus, hogy milyen egyszerűen beépíthető mindez egy webes/mobil felületre az alábbi JavaScript forráskóddal:

Mindössze egy regisztráció szükséges hozzá a Members OpenWeatherMap weboldalon a fenti forráskódba behelyettesítendő API kódért. Az egy sorba ömlesztve kapott forráskódot a Javascript Viewer, Beautifier and Formatter, Editor weblapon formáztam könnyen olvashatóvá.

Saját fejlesztés

Kedvet kaptam ezt a funkcionalitást összerakni úgy, hogy a hálózati kommunikációra helyeztem a hangsúlyt.
A nézet réteg ezért igen egyszerű, Java swing felületen, JFrame form-ként varázsolt az alábbiak szerint, mindössze JPanel és JLabel vizuális komponensekből áll. Egy JLabel osztályú komponens képes szöveg és/vagy kép megjelenítésére is.

aktuális időjárás Budapest

1. feladat

A modell rétegben tárolt település nevét és a szolgáltatás igénybevételéhez szükséges API kulcsot összerakva a Current weather data – OpenWeatherMap oldal specifikációját követve, megkapjuk az adatok lekérdezéséhez szükséges URL-t:

időjárás API URL

2. feladat

A hálózati kapcsolatot felépítve el kell kérni ( GET) az URL-ről kapott JSON formátumú adatot és tárolni kell azt a modellben ( jsonPuffer). A kivételkezelést nem részleteztem, mert most nem ezen van a hangsúly.

A jsonPuffer objektum ezt tartalmazza:

IdojarasJSON

A könnyen átlátható formátumot a JSON FORMATTER & VALIDATOR weblapon állítottam elő.

3. feladat

A JSON-t fel kell dolgozni és a különböző adatokat formázni/konvertálni kell, alkalmazkodva a megjelenítés igényeihez (például hőmérséklet Celsius fokban egész számra kerekítve, szélsebesség egytizedes pontossággal, hónap neve angolul, szükségesek a megfelelő mértékegységek). Külön gondoskodni kell arról, hogy az aktuális időjárást szimbolizáló ikonhoz (képként külön letöltve) is hozzájussunk, mert az API csupán az útvonalát jelentő URL-ből csak a fájl nevét (azonosítóját) adja meg. A kivételkezelést itt sem fejtettem ki.

4. feladat

Végül a modelltől elkért adatokkal frissíteni kell a nézetet.

Az eredmény

IdojarasBudapest


IdojarasLondon

IdojarasHouston

IdojarasTokyo

Aki kedvet kapott, annak többféle API is rendelkezésére áll, dokumentációval és példákkal együtt a https://openweathermap.org/api weboldalon. Kísérletezni bátran szabad, illetve érdemes megnézni és értelmezni azokat az adatokat, amiket JSON formátumban visszakapunk, de ehhez a feladathoz nem volt rájuk szükség.

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

A feladat a Java EE szoftverfejlesztő tanfolyam 9-12. óra: XML feldolgozás és 13-16. óra: JSON feldolgozás alkalmaihoz kapcsolódik.

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

érettségi logó

érettségi logóA 2018-as középszintű matematika érettségi feladatsor 10. feladata inspirált arra, hogy a programozás eszköztárával oldjuk meg ezt a feladatot. Szükséges hozzá néhány programozási tétel: sorozatszámítás, eldöntés, kiválasztás. Érdekes belegondolni, hogy mennyire más lehetne a problémamegoldás, ha programozhatnánk a matematika érettségi vizsgán. A teljes feladatsor a megoldásokkal együtt letölthető az oktatas.hu-ról.

10. feladat

Adja meg az alábbi adathalmaz móduszát, mediánját és terjedelmét!
2; 6; 6; 6; 6; 6; 3; 3; 4; 4; 4; 5; 5; 5; 5

Tervezés

A Java 8 által biztosított újdonságok közül használunk néhányat. Célszerű konstans tömbben tárolni a megadott számsorozatot, ami könnyen konvertálható generikus listába. Alkalmazkodni kell ahhoz, hogy a lista indexelése 0-tól lista.size()-1 -ig értelmezhető. Hasznos, ha a konkrét feladatok helyett általános megoldásokban gondolkodunk és a feladatot 3 metódusra bontjuk, amelyek ellenőrzéseket is végeznek. Például extrém esetek:

  • ha a lista üres, akkor nincs módusz, medián, terjedelem,
  • ha a lista egyetlen elemből áll, akkor a módusz és a medián megegyezik az elemmel, a terjedelem pedig nulla,
  • ha leggyakrabban több különböző szám is előfordul, akkor a módusz ezek közül a (leg)kisebb számot adja vissza.

Elvárjuk, hogy probléma esetén a metódusok dobjanak kivételt. Lényeges, hogy a referencia szerinti paraméterátadás során megváltozna a listában az elemek sorrendje, mert a megoldás igényli az elemek rendezettségét, akkor készüljön másolat az adatszerkezetről, hogy egy-egy részfeladat megoldása nem járjon azzal a mellékhatással, hogy az eredeti adatszerkezetben megváltozik az elemek sorrendje. Felhasználjuk a primitív típusú változók és a csomagolóosztályok közötti konverziós lehetőségeket: autoboxing és unboxing.

Megoldás: módusz

A módusz a lista leggyakoribb értékét adja meg. Másképpen az az érték, amelyik az adatsorban a legtöbbször előfordul.

A modusz() metódus átveszi a szamLista-t és készít róla lista néven egy másolatot, majd utóbbit növekvő sorrendbe rendezi. A másolat a Stream API-val készül el. Ezután csoportváltás algoritmussal feldolgozza a listát. Egy csoportba az azonos számok kerülnek és léptetés közben a belső ciklus megszámolja, hogy hány azonos szám alkotja az aktuális csoportot. Végül összehasonlítás következik a szélsőérték-kiválasztás ( aktSzamDb>maxAktSzamDb) beépítésével.

Megoldás: medián

A medián a lista középső értéke, amelynél az ennél kisebb és nagyobb elemek száma azonos. Rendezett adatsornál páratlan elemszám esetén a középső elem, illetve páros elemszám esetén a két középső elem átlaga.

A median() metódus átveszi a szamLista-t és készít róla lista néven egy másolatot, majd utóbbit növekvő sorrendbe rendezi. Ezután páros elemszám esetén visszaadja a két középső elem átlagát, illetve páratlan elemszám esetén a középső elemet. A metódusnak valós értéket ( double) kell visszaadnia, mert a két középső elem átlaga nem feltétlenül egész szám.

Megoldás: terjedelem

A terjedelem azt mutatja meg, hogy mekkora értékközben ingadoznak a lista elemei. A terjedelem az adatok változékonyságának „legdurvább” jellemzője, ami a szélsőértékek (minimum és maximum) közötti különbséget jelenti.

A terjedelem()  metódus átveszi a szamLista-t paraméterként és visszaadja a két szélsőérték különbségét, amelyek a Collections  osztály metódusaival könnyen előállítható. Persze egyetlen ciklussal is megkaphatnánk a két szélsőértéket.

Eredmény

A vezérlést az alábbi main()  metódus végzi el:

A konzolon az alábbi eredményt kapjuk:

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

A bejegyzéshez tartozó teljes forráskódot 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 17-28. óra: Objektumorientált programozás alkalmaihoz kötődik.

Java fejtörők – haladó

Java fejtörők

Java fejtörőkJava fejtörők – csapdák, buktató, és szélsőséges esetek. Ez egy könyv címe, amelynek szerzői J. Bloch és N. Gafter. Magyar nyelven a Kiskapu Kft. jelentette meg. A 2010-es magyar kiadás a 2005-ös angol nyelvű kiadás fordítása. A könyv weboldaláról (http://www.javapuzzlers.com), letölthető a 95 fejtörőhöz tartozó mintapéldák gyűjteménye, és elérhető a 270 oldalból minta fejezetként 28 oldalnyi tartalom 9 fejtörővel és azok részletes magyarázataival.

A két részre bontott blog bejegyzés a könyv anyagából válogatva készült el. Az első rész a bevezetés. Ez a második rész, haladó szintű példákkal. Néhány példát továbbfejlesztettem.

7. fejtörő: Mit ír ki program a konzolra?

Kivételkezelés nélkül arra számítanánk, hogy a Hello World! nem jelenik meg a konzolon, mert a wordHard() metódus feltétel nélkül rekurzív módon folyamatosan újrahívja önmagát és az emiatt keletkező StackOverflowError hibával elszáll a program. A kivételkezelés természetesen módosítja a program működését.

Ha azt feltételezzük, hogy minden Throwable utódosztályból futás közben létrehozott objektum kivételkezeléssel elkapható, akkor végtelen ciklusnak tűnik a vezérlés, hiszen a try blokkban hibát okozó metódushívásra a finally blokkban újra ugyanannak a metódusnak a meghívásával reagálunk, amelyik korábban a hibát kiváltotta. Ez a gondolatmenet tévút. A kulcsszó a rekurzív vezérlést megvalósító verem adatszerkezet mérete. Részletes indoklás a blog bejegyzés végén található.

8. fejtörő: Mit ír ki program a konzolra?

Természetesen NullPointerException-re gyanakszunk, pedig a program hibátlanul működik. A kulcsszó a statikus metódusok minősítése, vagyis annak jelölése, hogy melyik osztálytól vagy objektumtól kérjük annak végrehajtását. Részletes indoklás a blog bejegyzés végén található.

9. fejtörő: Mit ír ki a program a konzolra?

Arra számítunk, hogy a kiírás 1999-12, de ehelyett 2000 1-et látunk a konzolon. Tudjuk, hogy a Date osztály jó része már deprecated és ezen próbáltak javítani a Calendar osztállyal. Bár ne tették volna. A kulcsszó az ős dátumkezelést megvalósító API rejtelmeiben van. Részletes indoklás a blog bejegyzés végén található.

10. fejtörő: Mit ír ki a program a konzolra?

Nem tűnik egyértelműen eldönthetőnek a helyzet, ezért szintaktikai hibára gyanakodhatunk. Azonban a forráskód helyes, a program futás közben sem dob kivételt/hibát és a konzolon megjelenik a White. Szokatlan, hogy nagybetűvel konstansokat szokás jelölni, pedig nincs erre utaló final a forráskódban. A kulcsszó a sorrendiségen van, ha ugyanabban a hatókörben/blokkban van azonos nevű változó és típus/osztály. Részletes indoklás a blog bejegyzés végén található.

11. fejtörő: Mit ír ki a program a konzolra?

A program helyes és egyértelműnek tűnik. A konzolra az s1 szövegtömb elemei kerülnek ki véletlenszerűen összekeverve. Finomítsunk a kérdésen. Vajon minden lehetséges permutáció azonos eséllyel fordul elő? Ha ez a kérdés egyáltalán felmerül, akkor a válasz nyilván nem. A kulcsszó most egy kis matematika. Részletes indoklás a blog bejegyzés végén található.

12. fejtörő: Mit ír ki a program a konzolra?

Ez a forráskód nem úgy működik, ahogyan a könyv írja. Meglepő módon nem a [3, 1, 4, 1, 5, 9]-et adja, hanem az [1, 1, 3, 4, 5, 9]-et. Némi indoklás a blog bejegyzés végén található.

Részletes indoklások

  • 7. fejtörő: ha a try blokkban folyamatosan meghívja saját magát a workHard() metódus, akkor előbb-utóbb betelik a verem. Ekkor a finally blokkra kerül a vezérlés, ahonnan újra hívja saját magát a workHard() metódus. Persze követni kell, hogy a rekurzió végrehajtása során a lefelé haladó vagy a felszálló ágon vagyunk és nem mindegy, hogy melyik szinten. A háttérben egy teljes bináris fa bontakozik ki, amelynek mélysége azonos a verem méretével, mélységi korlátjával. Ezt a teljes bináris fát járja be a program, azaz mélységi fabejárás. Egy n mélységű teljes bináris fa elemeinek száma 2n-1. A verem mérete a virtuális gép beállításaitól függ, több ezer mélységű is lehet. Végtelen ciklusról tehát nincs szó. Ugye milyen izgalmas? További részletek a könyv 100-102. oldalán találhatók.
  • 8. fejtörő: a végrehajtás kiértékeli a statikus greet() metódus hívásának minősítő kifejezését, de figyelmen kívül hagyja a kapott értéket. A metódust végrehajthatnánk Null.greet()-ként vagy közvetlenül (minősítés nélkül) meghívva is. További részletek a könyv 122-124. oldalán találhatók.
  • 9. fejtörő: a Date osztály a hónapokat nulla bázissal kezeli, ezért csak 0-11-ig “van értelme”. Számíthatnánk a tömb vagy szöveg túlindexelésénél tapasztaltakhoz hasonlóan kivételre, de nem ez történik. A 12. hónap a következő év első/nulladik hónapját jelöli. Ezért látjuk a konzolon a 2000-et, amit egy kötőjel követ. A Date.getDay() deprecated metódus pedig a dátumobjektumban tárolt nap adott héten (nem hónapban!) elfoglalt helyét adja meg, ami nullával, azaz vasárnappal indul. Tehát a konzolon megjelenő 1 nem a 2000. januárt jelenti, hanem azt, hogy a 2000. január 31. hétfőre esik. Aki ezek után meri használni a régi dátumkezelő API-t, magára vessen. További részletek a könyv 141-143. oldalán találhatók.
  • 10. fejtörő: ha ugyanabban a hatókörben/blokkban van azonos nevű változó és típus/osztály, akkor a változó neve az elsődleges. Ha betartjuk a névadási konvenciókat ( ClassName, objectName, CONSTANT_NAME), akkor nem adódhatnak ilyen gondok. Még egy csavar van: ha az előző elnevezési módosításokat megtesszük, akkor a program a Black-et írja ki a konzolra. További részletek a könyv 161-163. oldalán találhatók.
  • 11. fejtörő: konkrét esetből általánosítunk. 4 elemre a ciklus 4-szer hajtódik végre és minden lépésben kiválaszt egyet a 0 és az 3 indexű elemek közül, ami 44=256-féle lehetséges eredményt ad. Ha az r objektum jól működik, akkor az egyes futások esélye/valószínűsége megegyezik. 4 elemű tömb elemeinek 4!=24 (faktoriális) féle permutációja (lehetséges sorrendje) van. Mivel a 256 nem osztható 24-gyel, így biztos, hogy a shuffle() metódus bizonyos permutációkat gyakrabban állít elő, mint másokat. Általánosan: nn nem osztható n!-sal, ha n>2 egész szám. Vajon mi történik, ha egy 52 lapos pakli kártyát keverünk össze? Vajon milyen érdekességet vet ez fel? Minden poént nem lövünk le itt a blogban. További részletek a könyv 228-232. oldalán találhatók.
  • 12. fejtörő: ez a tankönyv utolsó példája. A felvetett gondolat nagyon frappáns: az összehasonlító rész „ha fej, én nyerek, ha írás, te veszítesz” tüneteitől szenved. További részletek a könyv 232-233. oldalán találhatók.

 

Állásinterjúkon időnként visszaköszönnek hasonló fejtörők, de ezekkel óvatosan kell bánni. Egy programozási nyelv „joghézagainak”, buktatóinak, szélsőséges eseteinek ismerete a könyv szintjét elérő ismeretanyaggal nem lehet elvárt még egy meghirdetett senior pozíció esetén sem. Ezen fejtörők ismerete (vagy nem tudása) egy jelöltről nem árulja el a mindennapokban használható szakmai tudás meglétét/hiányát. De nyilván aki szakmailag folyamatosan fejlődik és mindenféle keretrendszert alkotó forráskódokban turkál, elemez, előbb-utóbb találkozik ezekkel/ilyenekkel.

Tanfolyamainkon nem kifejezetten foglalkozunk hasonló problémákkal, de azért időnként feszegetjük a határokat. Természetesen részletesen indokoljuk, ha előkerül valamilyen hasonló eset. Általánosságban nem célunk, hogy extrém eseteken keresztül, a programozási nyelv gyenge pontjaira kihegyezve oktassuk a Java programozási nyelvet.

Java fejtörők – bevezetés

Java fejtörők

Java fejtörőkJava fejtörők – csapdák, buktató, és szélsőséges esetek. Ez egy könyv címe, amelynek szerzői J. Bloch és N. Gafter. Magyar nyelven a Kiskapu Kft. jelentette meg. A 2010-es magyar kiadás a 2005-ös angol nyelvű kiadás fordítása. A könyv weboldaláról (http://www.javapuzzlers.com), letölthető a 95 fejtörőhöz tartozó mintapéldák gyűjteménye, és elérhető a 270 oldalból minta fejezetként 28 oldalnyi tartalom 9 fejtörővel és azok részletes magyarázataival.

Messze nem mai az anyag, de teljesen örökzöld. Ma is kifejezetten igazán izgalmas átgondolni ezeket a fejtörőket. Biztos vagyok benne, hogy az igazán profiknak is nyújt újdonságot egy-egy fejtörő mögötti részletes magyarázat. Sokszor kiderül az a ravasz és csavaros magyarázatok között, hogy mire gondolt a költő, azaz mi volt/lehetett a Java programozási nyelv tervezése során a szakemberek elképzelése, illetve előfordultak-e kompromisszumok, amiknek persze következményei vannak.

A két részre bontott blog bejegyzés a könyv anyagából válogatva készült el. Ez az első rész, bevezető, alapozó szintű példákkal. A második rész haladó szintű példákat tartalmaz.

1. fejtörő: Mit ír ki program a konzolra?

Két – literálként megadott – egész szám összegét kell kapni. Két egyforma értéket várunk: 66666. Mégsem ezt kapjuk. Az első kiírás 66666-ot, a második 17777-et jelenít meg a konzolon. A kulcsszó a különböző egész literálok megadása. Részletes indoklás a blog bejegyzés végén található.

2. fejtörő: Mit ír ki program a konzolra?

Szöveges literálokat hasonlítunk össze, amelyek egyforma ( length: 10) tartalommal jönnek létre. Döntések eredményeit várjuk, boolean típusú változókat. Négy sorba tördelve ezt kapjuk: false, false, Animals are equal: false, Animals are equal: true. A kulcsszó a művelet végrehajtás sorrendje, másképpen kifejezések kiértékelési sorrendje. Részletes indoklás a blog bejegyzés végén található.

3. fejtörő: Mit ír ki a program a konzolra?

Természetesen a megjegyzéssel nem törődünk és arra gondolunk, hogy a konzolon a Hello World! jelenik meg (a két kiíró utasítás eredménye egyetlen sorban egymás után) és nem is értjük, hogy mi a kérdés. Nyilván a helyzet nem ilyen triviális. A program nem futtatható. A kulcsszó az unikód escape szekvencia (védőkarakter). Részletes indoklás a blog bejegyzés végén található.

4. fejtörő: Mit ír ki a program a konzolra?

Nyilván szintaktikai hibát feltételezünk, de a program hibátlan és futtatva ezt látjuk a konzolon: browser::maximize. A kulcsszó a címke/utasításcímke. Részletes indoklás a blog bejegyzés végén található.

5. fejtörő: Mit ír ki a program a konzolra?

Gyanús a helyzet. Adott egy függvény, aminek kötelezően van visszatérési értéke. Ez rendben van. Tudjuk, hogy a return utasítás kiugrik a függvényből, eljárásból, ciklusból. A kivételkezeléshez kötődő nyelvi kulcsszavakat is ismerjük: try, catch, finally, throw, throws. Ezek működését is ismerjük. Azt feltételezhetjük, hogy a try blokkból kiugrunk true értékkel és a decision() függvényt meghívó main() metódusba visszatérve kiíródik a konzolra, hogy true. Mintha a finally blokk nem is lenne. Nem így történik. A programot futtatva false jelenik meg a konzolon. A kulcsgondolat a finally blokk végrehajtásának vezérléséhez kapcsolódik. Részletes indoklás a blog bejegyzés végén található.

6. fejtörő: Mit ír ki a program a konzolra?

Már biztosan gyanakszunk, de azért a Hello World!-öt várjuk a konzolon. Ehelyett nem jelenik meg semmi. A kulcsszó a puffer ürítés. Részletes indoklás a blog bejegyzés végén található.

Részletes indoklások

  • 1. fejtörő: int típusú literál az 54321, de long típusú literál az 5432l. Az 1 – mint numerikus karakter – nem egyezik meg a kis l betűvel. Tanulság: használjuk nagy L betűt a long típusú literálok végén. További részletek a könyv 11-12. oldalán találhatók.
  • 2. fejtörő: a konkatenálást végző + operátor erősebben kötődik, mint a két objektumreferencia azonosságát eldöntő == operátor. Az első kiírásban látható művelet igazából a második kiírásban látható zárójeles formában kerül végrehajtásra. A harmadik kiírást az magyarázza, hogy a String típusú literálokat memóriacímeik és nem a bennük tárolt karaktersorozat/érték alapján hasonítódnak össze. A helyes gondolatmenet implementálását a negyedik kiírás tartalmazza: (megegyezik-e a két szövegliterál tartalma). További részletek a könyv 29-31. oldalán találhatók.
  • 3. fejtörő: a megjegyzés 3. sorában található \u karaktert 4 db hexadecimális számnak kellene követnie. Ez hiányzik, ami szintaktikai hibát jelent. További részletek a könyv 33-34. oldalán találhatók.
  • 4. fejtörő: az URL-ben lévő : egy ugyanolyan címke, amit a switch utasításban a case ágaknál szokás használni. Ez így is megengedett, de teljesen haszontalan. További részletek a könyv 47-48. oldalán találhatók.
  • 5. fejtörő: a kivételkezelési mechanizmus úgy működik, hogy a try blokkban lévő utasításoktól függetlenül – akár volt kivétel akár nem, akár return utasítást tartalmaz a try blokk – a finally blokk mindenképpen végrehajtódik. Ebben az esetben a kivételkezelési mechanizmus erősebb. További részletek a könyv 77-78. oldalán találhatók.
  • 6. fejtörő: a System.out egy PrintStream osztályú objektum. Többnyire automatikusan ürítik az átmeneti tárolóját az ezt használó utasítások, például System.out.print() és println(). A write() metódus nem üríti ezt a puffert. További részletek a könyv 195-196. oldalán találhatók.

 

További hasonló Java fejtörők, érdekességek

Tanfolyamainkon nem kifejezetten foglalkozunk hasonló problémákkal, de azért időnként feszegetjük a határokat. Természetesen részletesen indokoljuk, ha előkerül valamilyen hasonló eset. Általánosságban nem célunk, hogy extrém eseteken keresztül, a programozási nyelv gyenge pontjaira kihegyezve oktassuk a Java programozási nyelvet.

Ez volt az első rész, bevezető, alapozó szintű példákkal. Jöhet a második rész haladó szintű példákkal.