- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Magga: PLEX: multimédia az egész lakásban
- Szoszo94: Xiaomi Mi Router 3G - Padavanra fel!
- gban: Ingyen kellene, de tegnapra
- eBay-es kütyük kis pénzért
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- btz: Internet fejlesztés országosan!
- antikomcsi: Celebtanya - Farm VIP V.
Új hozzászólás Aktív témák
-
Lortech
addikt
válasz
Ablakos
#11899
üzenetére
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)
-
Ablakos
őstag
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());??????????????} -
#11897
sztikac
őstag
yossarian14
#11896
sztikac
őstag
válasz
yossarian14
#11896
üzenetére
Huh, ha hiszed ha nem kb. 25x átfutottam ezt a kódrészletet és az agyam automatikusan így dolgozta fel:
public boolean equals(Person compared) {...}Köszi!
-
sztikac
őstag
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
-
Ablakos
őstag
válasz
Szmeby
#11889
üzenetére
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.) -
Szmeby
tag
válasz
Ablakos
#11888
üzenetére
A
partreferenciája nem szűnik meg, ha arra gondoltál. A belepakolt Stringeket a clear ugyan eltávolítja a listából, de aparté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, apartreferenciáját megjegyzi a recipe ojjektum is - immáron nem csak apartváltozó fog arra hivatkozni -, az ő referenciáját pedig beledobjuk alistRecipeslistába, így az már nem vész el addig, amíg alistRecipeslétezik.Tehát a clear helyett bátran csinálhatsz egy új lista objektumot a
partváltozódnak, sőt illene is, ha nem akarod piszkálni a régi lista tartalmát, ami már alistRecipesbugyraiban pihen. -
Ablakos
őstag
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
butterMeatballs
20
ground meat
egg
breadcrumbsTofu rolls
30
tofu
rice
water
carrot
cucumber
avocado
wasabiA 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;} -
btraven
őstag
válasz
Drizzt
#11881
üzenetére
É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.
-
axioma
veterán
-
BE4GLE
aktív tag
válasz
axioma
#11882
üzenetére
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. -
floatr
veterán
válasz
BE4GLE
#11878
üzenetére
Ö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. -
axioma
veterán
válasz
floatr
#11876
üzenetére
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. -
Drizzt
nagyúr
válasz
btraven
#11879
üzenetére
[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. -
BE4GLE
aktív tag
válasz
btraven
#11879
üzenetére
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. -
BE4GLE
aktív tag
válasz
btraven
#11873
üzenetére
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.
-
floatr
veterán
válasz
axioma
#11875
üzenetére
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... -
axioma
veterán
válasz
Drizzt
#11874
üzenetére
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.) -
-
BE4GLE
aktív tag
-
Szmeby
tag
válasz
Ablakos
#11866
üzenetére
A
containsteljeskörűen működik. Ha belenézel azObjectosztályba (ami minden osztály őse), láthatod, hogy azequalsmetó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 acontainsalapé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
newutasí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 anewutasí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 aBook b2 = new Book("a", 1);eltérő referenciával bír, az alapértelmezettequalsszerint ők különböző objektumok. Míg aBook b3 = b1;ugyanazzal a referenciával bír, mint a b1 objektumod, az alapértelmezettequalsszerint ők ugyanazok az objektumok. -
Drizzt
nagyúr
válasz
Ablakos
#11864
üzenetére
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)
-
Ablakos
őstag
válasz
Drizzt
#11863
üzenetére
Mindössze két tag változó van a Book osztályban:
private String name;private int publicationYear;
-----------------------------------------------------------//------------@Overridepublic 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);} -
Drizzt
nagyúr
válasz
Ablakos
#11862
üzenetére
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.
-
-
Drizzt
nagyúr
válasz
Ablakos
#11860
üzenetére
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.
-
Ablakos
őstag
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());}} -
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.)
Előtte nem tudtam, hogy a contains (teljeskörű) működéséhez azt is meg kell írni.
Coming soon... 
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Leépíti a Sony az európai piacot?
- Elektromos autók - motorok
- Androidos tablet topic
- Nintendo Switch 2
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- EAFC 25
- Samsung Galaxy Watch6 Classic - tekerd!
- 3D nyomtatás
- Milyen SSD-t vegyek?
- Mibe tegyem a megtakarításaimat?
- További aktív témák...
- ÚJ ÁRU, OLCSÓBB!!! Dell Precision Workstation 5550, 5560, 7510, 7520, 7550, 7720, i7, 6-11. gen.
- Apple iPhone 7 128GB, Yettel függő, 1 Év Garanciával
- Telefon felvásárlás!! Honor 200 Lite, Honor 200, Honor 200 Pro, Honor 200 Smart
- ÁRGARANCIA! Épített KomPhone i9 14900KF 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Azonnali készpénzes nVidia RTX 3000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest