Én a kilépő ágat try-catch blokban csináltam volna. Lekezelve a NumberFormatException kivételt. Az az if (number == -1) nem tudom mitől véd egész pontosan.

[ Szerkesztve ]

Redmi Note 9 Pro

Ebben a tanulási fázisban (szerintem) még nem ismert az exception.

[ Szerkesztve ]

Ezesetben bocsi a SPOILER miatt. Coming soon...

Redmi Note 9 Pro

if (number == -1) nem véd semmitől, feladatban volt úgy megadva, hogy -1 beírása esetén hagyja abba a számok beolvasását.

#11853: máshonnan (C) ismerős az exception, de Java-ban még nem tartok ott és nem is volt a feladat része.

Én is bejelentkeztem erre a kurzusra. Kíváncsi vagyok milyen ez a (ha jól látom finn) e-learning.

A paraméteres try mindig volt, vagy csak nekem újdonság?

Java 7 óta van (szóval nem mai darab), és try-with-resources néven tudsz utánanézni.

Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!

Köszönöm, már meg is van. Az alapszintű OCA nem is említi, csak az OCP-ben van kifejtve.

[ Szerkesztve ]

Egy kis szakértést szeretnék kérni, mert nem tudom megfejteni miért nem akar a contains metodus nekem működni. (book class a simple pojo)
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
ArrayList<Book> books = new ArrayList<>();

while (true) {
System.out.println("Name (empty will stop):");
String name = scanner.nextLine();
if (name.isEmpty()) {
break;
}

System.out.println("Publication year:");
int publicationYear = Integer.valueOf(scanner.nextLine());
Book book = new Book(name, publicationYear);
if (books.contains(book)) {
System.out.println("The book is already on the list. Let's not add the same book again. \n Name (empty will stop):");
} else {
books.add(book);
}

System.out.println("Thank you! Books added: " + books.size());
}
for(Book b:books) {System.out.println(b.getName() + " " + b.getPublicationYear());}
}

[ Szerkesztve ]

Az Arraylist contains hasznalja az equalst. Ha nincs korrektul implementalt equals a Book classban, akkor csak abban az esetben fog igazat adni, ha ugyanazt a referenciat tartalmazza az egyik, meg a masik book. Erdemes viszont akkor mar hashCode-ot is implementalni, mert mas kollekciok hasznalhatjak azt is a contains eldontesehez.

I am having fun staying poor.

Azt hittem olyan csoda metódus a contains. Akkor mi értelme a contains-nek?
Az eddigi (oktatási) feladatokban is override-oltam az equals-t és az jól is üzemelt. (referenciát és minden változót végigvizsgálva az objektumban)

[ Szerkesztve ]

A contains megmondja, hogy érték alapján van-e egyező elem az adott kollekcióban azzal az objektummal, amit paraméterként kapott. Azt, hogy érték szerint megegyezik-e valami, az equals metódus jelenti a Javaban. Ha van szerinted jó equals és nem így működik, akkor mutasd meg az equals-odat.

I am having fun staying poor.

Mindössze két tag változó van a Book osztályban:
private String name;
private int publicationYear;
-----------------------------------------------------------//------------
    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        } else if (!(obj instanceof Book)) {
            return false;
        }
        return (((Book) obj).name.equals(this.name) && ((Book) obj).publicationYear == this.publicationYear);
    }

[ Szerkesztve ]

Akkor nem értem a problémát, nálam teljesen jól működik:

Name (empty will stop):
mybook
Publication year:
1
Thank you! Books added: 1
Name (empty will stop):
mybook
Publication year:
1
The book is already on the list. Let's not add the same book again.
Name (empty will stop):
Thank you! Books added: 1
Name (empty will stop):
yourbook
Publication year:
2
Thank you! Books added: 2
Name (empty will stop):
mybook 1
yourbook 2

(Thank you! Books added: egy picit félrevezető kiírás, mert akkor is jön, ha nem adtunk hozzá semmit)

I am having fun staying poor.

Most már, működik. Miután elárultad, hogy az equal-t is meg kell valósítani. (override) Előtte nem tudtam, hogy a contains (teljeskörű) működéséhez azt is meg kell írni.

Köszönöm.

A contains teljeskörűen működik. Ha belenézel az Object osztályba (ami minden osztály őse), láthatod, hogy az equals metódus referenciák egyenlőségét vizsgálja - lévén más információja nincs az osztályról. Azt csinálja, mint amit az == operátor.

Tehát az equals és egyben a contains alapértelmezett működése az, hogy csak akkor tekint két objektumot egyenlőnek / a lista egy tagjának, ha az az objektum ugyanaz az objektum, mondjuk úgy, hogy ugyanazon a memóriacímen található adathalmaz.

Abban a pillanatban, hogy kiadod a new utasítást, a jvm egy vadonatúj objektumot fog gyártani neked. Még ha ugyanazt a szöveget adod is meg neki a könyv címe paraméterben, még ha ugyanaz az évszám, még ha látszólag ugyanúgy is néz ki az az objektum, mint egy másik, a referenciájuk eltér, hiszen a new utasítással ezt kérted a jvm-től, egy új objektumot.

A referencia alapú összehasonlítás időnként hasznos dolog, de a modelljeinkben többnyire nem ez a legjobb megoldás. Ezért készítünk az objektumainknak saját equalst, amikor azokat egymással össze akarjuk hasonlítani, és azt várjuk el tőle, hogy egyenlőnek tekintsen két könyv objektumot, ahol a cím és az évszám egyenlő. Ezt sajnos meg kell írnod, mert a jáva túl buta, hogy kitalálja a programozó gondolatait, elvárásait.
(És készítünk nekik saját hashcode implementációt is, amikor azokat mondjuk HashSet-ben kívánjuk gyűjtögetni, vagy HashMap kulcsaként akarjuk felhasználni.)

Tehát a Book b1 = new Book("a", 1); és a Book b2 = new Book("a", 1); eltérő referenciával bír, az alapértelmezett equals szerint ők különböző objektumok. Míg a Book b3 = b1; ugyanazzal a referenciával bír, mint a b1 objektumod, az alapértelmezett equals szerint ők ugyanazok az objektumok.

Egy érdekesség: Java 14-től bevezették a record class-t. Szóval ha azt használod, akkor nem kell ilyen boilerplate kódokkal vacakolnod.

Redmi Note 9 Pro

Értem és köszönöm a magyarázatot.

Vagy lombok.

Mennyire használják a gyakorlati fejlesztésben a metódus tesztelés (assert) technikát? Érdemes komolyabban elmélyülni vagy elég az "ezt is láttám már" tudás?

Sok cég projektjébe be se lehet mergelni olyan kódot, ami nincs letesztelve. Szóval jobb ha megbarátkozol velük, és úgy általában a TDD-vel, mert ha csak nem valami kontár projekten dolgozol, akkor legalább egy code coverage ellenőrzés le fog futni a projekten.

Redmi Note 9 Pro

A TDD zseniális ötlet.
De azért ara kíváncsi vagyok hogy a gyakorlatban hány cég fejleszt ezzel.
Kiderül hogy 1-2, de azok is megbánták.

Nagyon teves feltetelezes. Konkretan van ceg, ahol a felveteli reszekent TDD-ben kell megoldanod a feladatot. Mivel - meglepeteeees - TDD alapon dolgoznak. En viszonylag keves dolgot fejlesztettem TDD-ben, de amit igen, az mindig meghalalta.

I am having fun staying poor.

Nalam a tdd ott bukik, hogy mikor me'g semmi nincs a szoftverbol csak tervek, akkor forditjak le a kovetelmenyeket tesztesetekre. Ami meg csak akkor mukodik jol, ha vagy eleve valami mechanikus, a kimenetekkel csak elgepelest ellenorzo a feladat [protokoll vagy kodolas stb. megvalositasa], vagy meglevo 10 eve futo cuccba +1 feature, ahol minden mas kobe van vesve, nincs fejlesztoi dontesi helyzet. Ezektol eltero esetben nagy esellyel lesz menet kozbeni varialas vagy olyan fontos kepesseg amit elfelejtettek tesztesetbe fogalmazni, mert annyira trivialis ha az egeszet nezne a fejleszto, nem csak a fixalando teszteseteket egymas utan.
(Az meg nem tdd, hogy ir teszteket, ir ettol fgtl a kovetelmenyekbol egy szoftvert, es mikor kilora kesz akkor engedi ra a teszteket, es kezd javitgatni. Legalabbis szvsz.)

Túl cinikus vagyok a TDD-hez
Az utóbbi években csak olyan agilis projektekben dolgoztam, ahol az agilitás leginkább arra vonatkozott, hogy menetközben találja ki a megrendelő, hogy mit is akar (vagy nem). A projektek óriási keretrendszereket használnak, amiben az egyes funkciók deklaratív elemeken keresztül automatikusan készülnek el. Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek.
Ha ilyen projektekre valaki rávág egy coverage kritériumot, mert az jól mutat, a teljes csapat egy emberként áll fel, és megy át a konkurenciához.
De hello ${username} példakódban piszkosul jól mutat...

Nálunk se jutnál keresztül a felvételi folyamaton enélkül. És nem tudom miről beszélsz. Én sosem bántam meg. Az olyan kódokkal viszont nagyon nehéz dolgozni, amik teszt nélkül össze lettek gányolva. Már csak azért is, mert az ilyen kódok jellemzően később se teszteletőek. Egészen máshogy írsz meg valamit, ha a tesztelhetőség és karbantarthatóság is szempont, és nem csak az, hogy minél előbb legyen egy látszólag működő funkciód.

Redmi Note 9 Pro

Amit leírtál az távolról sem agilis fejlesztés. A rossz menedzsment mindig rányomja a bélyegét a projektminőségre. Ez nem a TDD hibája.

Redmi Note 9 Pro

Ha már Hello World.
Azt hogy kell TDD-ben csinálni?
Hogy állapítja meg a teszt hogy kiírta-e a képernyőre hogy Helló világ?
És a jó pozícióba. Nem csak Helló vi és a lág meg kilóg oldalt.

Ha ez a kérdés fölmerült benned az számomra azt sugallja, hogy nagyon nem tudod mire való egy unit teszt. Vagy csak trollkodsz. Az ilyen tesztekben az interface-eket mock-olod. A user interface-t is. Nem célja ezeknek a teszeknek ellenőrizni, hogy a layout-ot helyesen raktad e össze, és hogy a szöveged jól legyen tördelve. Viszont a Hello World-ig vezető utat le tudod tesztelni és a kimenetet is.

[ Szerkesztve ]

Redmi Note 9 Pro

[Például]
De egyébként A hello world egy unit tesztelhetőség szempontjából pont eléggé faramuci dolog, mert ott a függvényedet le kellene választani a környezetéről. Ha nem a környezetéről leválasztva tesztelsz valamit, akkor az az én szememben már inkább integration teszt.
Egy olyan függvényt, ami a standard outputra kiírja, hogy Hello world, nem lehet jól unit testelni, mert a standard outputot kell mockolni, ami meg csak ilyen nyakatekert módokon oldható meg.
Ha viszont olyan függvényed lenne, ami visszaadja, hogy: "Hello world" -> remekül unit tesztelhető. Olyan, ami kap egy outputstream-et input-ként és kiírja rá, hogy "Hello world" -> szintén remekül unit testelhető.
"Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek."
Ez utóbbi mindig nagyon gyanús. Én is mindig azt hiszem, ogy jó, triviális kódokat írok, aztán amikor elkezdem tesztelni, szinte mindig kijön valami turpisság. Nyilván a tesztelés mehet három módon: kézzel pöcögtetve: valószínűleg jó kódot eredményez, de ha legközelebb aki hozzányúl, nem olyan alapos, mint aki írta és kézzel tesztelte, akkor rögtön veszélyes lesz módosítani a kódot. 2.: vagy azonnal automata tesztet írni, vagy az előző pont kézi eseteit automatizálni. Ez elég jó általában. 3.: előre írni meg a tesztet és csak utána a kódot. Pont az a nagy előnye, ami miatt elsőre nagyon nehéz vele dolgozni: végig kell előre gondolni az elvárt viselkedést és a trükkös eseteket is. Erre gyakran használt kifogás, hogy sokat változik az elvárás, azért nem kezdenek vele. De nem teljesen korrekt érv, hiszen anélkül, hogy tudná mit akar csinálni az ember, el sem tud mit kezdeni programozni.
Én tényleg csak alkalomszerűen TDD-zek, de örülnék, ha valamikor elkezdenénk végignyomni vele teljes projekteket, mert minőségben ég és föld a különbség. Ha előre írsz tesztet, akkor sokkal jobban át tudod gondolni, hogy milyen osztályoknak, milyen interface-eken keresztül kell tudniuk egymással beszélni. Sokkal könnyebb elkerülni a spagetti kódokat.

I am having fun staying poor.

Vagy csak olyanok kozott dolgozom akik a problemat oldjak meg a szoftver letrehozasaval es az implementacio helyesseget tesztelik megfelelo szintu tesztekkel utat helyesebbnek tartjak.
Tesztet irni TDD-hez DE ugy, hogy az tenyleg minden lehetseges implementacio eseten minden hibat elkap, akkora befektetes, hogy annyi ido alatt az _egyik_ implementaciot tesztelessel egyutt egy-harom masik problemara is megcsinalja [JOL]. Teljes tesztet elore megirni ugy, hogy egy lehetseges implementacio mar a fejeben van, az meg a menet kozben kiderulo donteseknel csinal lyukat [aztan vagy betomik vagy nem... talan ahol merge feltetelbe fut].
Egy esetben jo lehet: az "agy" irja a teszteket, a code monkey-k/juniorok/etc. meg az implementaciot. De akkor sem biztos hogy kicsit is hosszabb tavra nezve.
[Termeszetesen az elozoleg irt kiveteleket fenntartva, altalanosabb meretu/beagyazottsagu/bonyolultsagu fejlesztesi feladatokra.] Es persze SZVSZ.

Örülök h sikerült ennyiből meglátni minden aspektusát.

#11881 Drizzt
Többek között azért is más a minőség, mert sokkal jobban végiggondolt az egész. Szinte már waterfall

#11879 btraven
Ha már rendszerszemlélet, dobd bele egy bootba, kapja meg webfluxon a nevet, majd küldje el egy ELK-nek a generált szöveget. Tedd a szöveg generálást egy service-be, amire írhatsz 1 darab unit tesztet, minden másnál mókolsz, meg integrálsz, és többször becsapod magad.

#11882 axioma
Ezért mondom, hogy ehhez túl cinikus vagyok. De az már megint nem agilis, ha droidokkal dolgozol. Ráadásul a tesztelt kód többszörösét megírod, ahol a tesztben ugyanúgy lehet hiba, amin átsiklasz, mert rosszul tesztel.

[ Szerkesztve ]

Nem értem mi igényel ebben olyan sok időt. Az én tesztjeim nem szoktak olyan robosztus kódok lenni. Hiszen csak pár mock adat, fake hívás, és assert az egész. Viszont a teszt nélküli legacy kódok javítására borzalmasan sok idő megy el. A menet közben kiderülő döntések pedig mindenképpen megkavarják a dolgokat. Ez nem érv a TDD-vel szemben.

Redmi Note 9 Pro

Vak vagyok, kevertem a ket mikulast, mea culpa... es azt gyorsolvastam h engem cinikusozol, hiaba nem is allt ossze az agilis sztoriddal. [Pedig szabin vagyok, igaz lakasatrendezes miatt nem tul kipihent.]
A velemenyem all, csak nem neked kellett volna cimeznem.

Én csak azt ismerem TDD-nek amit a 3. pontban írsz.
Programkódot nem szabad írni amíg a teszt nincs meg.
És nem szabad újabb tesztet írni amig nincs kész az előző tesztre a jó program.
unit teszt az más tészta, azt lehet írogatni szabadon a program mellett.
Tehát ha valaki unit tesztet használ az még nem TDD.

De lehet rosszul tudja, Robert C. Martin könyvében olvastam.

Ezzel nem mondasz ellent annak, amit mondtam. Sehol nem állítottam, hogy az első 2 TDD lenne.

I am having fun staying poor.

Egy kis segítséget szeretnék kérni. A mellékelt txt részlet (recept) szerkezetet szeretném listába olvasni. (A receptek üres sor szeparáltak. Recipe osztály 1db arraylist példány változót tartalmaz.)
Pancake dough
60
milk
egg
flour
sugar
salt
butter

Meatballs
20
ground meat
egg
breadcrumbs

Tofu rolls
30
tofu
rice
water
carrot
cucumber
avocado
wasabi

A tervem: string listába (part) tettem a sorokat és file üres sor esetén ezt a listát odaadtam a recepies listának, ami az osztályt tárolja. A gondom, hogy a part.clear(); hívással az átadott referencia is megszűnik. Hogy lehetne ez jól megoldani?

public static ArrayList<Recipe> readRecordsFromFile(String fileName) {
    ArrayList<Recipe> listRecipes = new ArrayList<>();
    ArrayList<String> part = new ArrayList<>();
    try {
      Scanner file = new Scanner(Paths.get(fileName));
      while (file.hasNextLine()) {
        String[] str = file.nextLine().split(System.lineSeparator());
        if (str[0].equals("")) {
          listRecipes.add(new Recipe(part));
          part.clear();
        } else {
          part.add(str[0]);
        }
      }
      if (!part.isEmpty()) {
        listRecipes.add(new Recipe(part));
      }
    } catch (IOException ex) {
      Logger.getLogger(RecipeSearch.class.getName()).log(Level.SEVERE, null, ex);
    }
    return listRecipes;
  }

A part referenciája nem szűnik meg, ha arra gondoltál. A belepakolt Stringeket a clear ugyan eltávolítja a listából, de a part él és virul. Egy referencia akkor szűnik meg, amikor semmilyen más élő objektum nem hivatkozik rá (mert mondjuk az utolsó hivatkozást is felülcsapod valami más referenciával).
Na meg a vezérlés kifutott a scope-jából is, ami a part esetén a metódus kapcsos zárójelei között található. (Ha a while ciklus kapcsos zárójelei közé tennéd a part deklarációt, akkor az lenne az ő scope-ja és minden körben új példány készülne belőle, de azt most nem akarod.)

A csoda a listRecipes.add(new Recipe(part)); soron történik, a part referenciáját megjegyzi a recipe ojjektum is - immáron nem csak a part változó fog arra hivatkozni -, az ő referenciáját pedig beledobjuk a listRecipes listába, így az már nem vész el addig, amíg a listRecipes létezik.

Tehát a clear helyett bátran csinálhatsz egy új lista objektumot a part változódnak, sőt illene is, ha nem akarod piszkálni a régi lista tartalmát, ami már a listRecipes bugyraiban pihen.

[ Szerkesztve ]

Köszönöm, teljesen világos. Tehát a part.clear() helyett egy part = new ArrayList<>() a megoldás.
(Sajnos az elmélet és a gyakorlat még nincs szinkronban nálam. Tudom, hogy referenciával megy az objektum másolás, de én foxi módra eltökéltem hogy átmásolódik az egyik lista tartalma a másikba.)

Aztán ha ez megvan, jöhet a streames-collectoros megoldás is

Valszeg lesz ilyan szintű kérdésem is, de egyelőre a tudás színvonalam a lenti mértékkel bír.

Itt esetleg?
https://java-programming.mooc.fi/faq#heading-i-think-one-of-the-programming-exercises-has-a-bug

Ha már MOOC... Van ez a kód:

public boolean equals(Object compared) {
// if the variables are located in the same position, they are equal
if (this == compared) {
return true;
}

// if the compared object is not of type Person, the objects are not equal
if (!(compared instanceof Person)) {
return false;
}

// convert the object into a Person object
Person comparedPerson = (Person) compared;

// if the values of the object variables are equal, the objects are equal
if (this.name.equals(comparedPerson.name) &&
this.age == comparedPerson.age &&
this.weight == comparedPerson.weight &&
this.height == comparedPerson.height) {
return true;
}

// otherwise the objects are not equal
return false;
}

Itt nem igazán értem, hogy a type cast-ra (Person comparedPerson = (Person) compared;) mi szükség van, hiszen a metódus már megkapja a compared objektumot

Ha megnézed a metódus paraméterét, akkor láthatod, hogy Object típussal érkezik be. Ahhoz hogy össze tud hasonlítani a különböző Person specifikus fieldeket, először le kell castolnod, hogy elkérhesd őket.

Adott egy Counter és SubCounter, amely extendálja a Countert. Mindegyikben egy gc() methódus. A kérdésem, hogy a ciklusban (kérdőjeleknél), hogyan tudom az override-olt ősosztály gc()-t hívni?

      ArrayList<Counter> cList = new ArrayList<>();
        cList.add(new SubCounter());
        cList.add(new Counter());
        
        for(Counter list:cList) {
            System.out.println(list.gc());      
         ??????????????   
        }

[ Szerkesztve ]

Itt a gc egy példányszintű metódus (instance method), ami késői kötést (late/dynamic binding) használ, így a Counter futásidejű típusa határozza meg, hogy melyik gc() metódus implementáció hívódik meg (polimorfizmus). Ha SubCounter újradefiniálta (override) a gc()-t, akkor ha a list változód futás idejű típusa SubCounter, akkor az override-olt változat fog hívódni, nem tudod meghívni a Counter gc() metódusát azon a példányon keresztül.

(azért írtam zárójeleket, hogy jobban utána tudj nézni ezeknek a fogalmaknak)

[ Szerkesztve ]

Thank you to god for making me an atheist