- gban: Ingyen kellene, de tegnapra
- MasterDeeJay: Legolcsóbb "x99" gép építése. (folyamatban)
- MasterDeeJay: Low budget (50.000 forint) light gémer gép összerakása
- Magga: PLEX: multimédia az egész lakásban
- Luck Dragon: Asszociációs játék. :)
- Nyuszit otthonra, kedvencnek!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: Anker Charger (140W, 4-Port, PD 3.1) laptop, mobil, tablet töltő
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
Új hozzászólás Aktív témák
-
"Hmm. Azt hiszem, te többet láttál bele a kérésbe, mint én."
Ez igaz....én csak a vaskalapos, merev és felesleges kérdéseket nem szeretem...
"Ha neked tennék fel a kérdést egy interjún, hogy szerinted milyen egy jó, minőségi java osztály implementációja, akkor mit válaszolnál?"
Megkérdezném a kérdést feltevőt, hogy valóban, ezt az interjúra szánt 10 percet akarja arra felhasználni, hogy megtárgyaljuk, mitől lesz szép egy java kód? Vagy inkább ténylegesen ki akarja deríteni fogok-e tudni hatékonyan együtt dolgozni abban a csapatban, vagy annak az élén ahova épp embert keresnek. Mert pl én azért vagyok épp ott, hogy megtudjam ezt (a java kódkonferenciára ki se öltöztem volna).
Hála égnek, ilyen interjún nem voltam soha, és nem is voltam kényszerhelyzetben, hogy bele kellet volna mennem ilyenbe...Eddig mindig egy kötetlen, informális beszélgetésbe csöppentem, ahol a szűk szakmai dolgokról nem volt szó. Alapértelmezett volt, hogy ha kovácsnak jelentkezem és ők kovácsot keresnek, akkor nem kérdés, hogy mindketten tudjuk, milyen a felpattanó szikrába belenézni (ha ez nem így volna, úgyis kiderülne, egy héten belül)
20 éves tapasztalattal a hátam mögött pedig az a véleményem, hogy egy IT projekt legutolsó, szinte lényegtelen része, hogy mennyire szépen, mennyire jó minőségben (sic) vannak implementálva a java osztályok. (nyilván számít a kód milyensége, de nem ezen fogunk elbukni... mielőtt valaki visszadobná a labdát)
"A felhozott példákat én egy lehelletnyit túlzónak tartom"
A példák, mindig valami túloznak...
Értelek, egy 20 éves tapasztalattal rendelkező jelentkezőnél valóban béna dolog a kódminőség felől érdeklődni, tiszta sor. Ezer ennél relevánsabb kérdést is feltehetnének. Ugyan korrigálhatnám a neked feltett kérdésemet úgy, hogy mit válaszolnál a kérdésre akkor, ha junior lennél egy junior pozira, de érzem, hogy a válaszod ugyanaz lenne.
Nekem nincs ennyi év a hátam mögött, de úgy vélem 20 éves múlttal sem feltétlenül sértődnék meg egy ilyen kérdésen, szerintem ha ez érdekli az interjúztatót a legjobban, akkor szíve joga rákérdezni. Nyilván annak is tudatában van a HR (ha meg nincs akkor így járt), hogy egy ilyen kérdés feltevése milyen színben tünteti fel őket. Szerencsére az állásinterjún a felvételizőnek is van lehetősége arról beszélgetni, amiről konkrétan ő szeretne, és én jelöltként is ugyanúgy elvárom a felvételiztetőtől, hogy készséggel válaszoljon a kérdésemre, mint fordított helyzetben. Nem kellemes, amikor megítélik az embert a feltett kérdése alapján. De legalább hamar kiderül, hogy nincs meg az összhang, próbaidő sem kell ennek a megállapításához.
Talán azért ez a véleménykülönbség, mert sokat szívtam legacy kóddal, és sokkal jobban megérint a kódminőség (hiánya), mint másokat. És mivel eddig szinte minden kollégámmal jól kijöttem, annyira nem szokott érdekelni, mennyire jól tudok velük együtt dolgozni... eddig mindig sikerült jól együtt dolgoznunk. Esetedben meg talán máshol vannak a hangsúlyos pontok.
Ez az oka annak is hogy ráugrottam a hozzászólásodra, mert mérhetetlenül sajnálatosnak tartom, hogy a menedzserek mellett sok fejlesztő is tesz a minőségre (szinte lényegtelen összetevőnek tartják), és nem látják, hogy ezzel a saját vagy sorstársaik életét teszik pokollá hosszú távon. Azt hiszem a válaszaimmal igazából csak keresem a megerősítést, hogy valóban az a jó irány, ha a határidőt, a rövid távú sikereket tartja az ember szem előtt. Egyelőre nem sikerült meggyőznöm vagy meggyőzetnem magam, de igyekszem.
----
PeachMan:
Hogy ON is legyek, nálam a model az entitás réteget jelenti - vagy perzisztens réteget, ahogy te fogalmazol. POJOk, amelyek már jávául íródtak, de közvetlenül a DB-be mentjük őket és DB-ből töltjük fel őket. Az ORM akítvan használja őket, lévén ők képezik az O-t az ORM-ben.
A DTO (Data Transfer Object) pedig adatok továbbításáért felel a komponensek között, ez jellemzően magasabb rétegekben jelenik meg (ha a perzisztens réteg van alul és a view felül).Hogy mennyire szép elfelejteni a DTO-kat és mindenhol csak a modelt használni, nos, szerintem ez komplexitás kérdése. Egy szép világban nem lenne szükség DTO-ra, mert minek lekopizni valamit pusztán azért, hogy 2 service beszélgetni tudjon egymással. De van egy rakás oka, amiért mégis van létjogosultsága.
Lehet technológiai oka, mondjuk az ORM meg tud zavarodni, ha egy entitásban több collection is van, DTO-k bevezetése jó workaround tud lenni. Te is említetted, hogy a view-nak nincs szüksége minden mezőre, ez is egy valid ok. Főleg akkor, ha nemcsak nincs szüksége, hanem egyenesen tilos egy view-nak látnia minden adatot. Lehet ok a sebesség optimalizálás. Ha egy view-nak csak 1-2 mező kell egy 20 oszlopos táblából, nagyon nem mindegy, hogy mind a 20 mezőt áttolod-e egy microservice-ből a másikba, vagy csak a szükségeseket. Egy DTO-t létre lehet hozni azzal a 2 szükséges mezővel és azt passzolgatni. Az sem mindegy, hogy egy entitásban a kapcsolódó táblák adatai is feltöltésre kerülnek vagy sem, és erre a view-nak szüksége van-e vagy sem. Van, hogy az ORM-et megkerülve jpql vagy akár natív sql végrehajtásával kell felszívni bizonyos adatokat, mert annyira tetü lassú lenne máskülönben, hogy a user megunja az életét. Ez már egy optimalizációs indok lehet, és nem is a fejlesztés legelején kell erről gondolkodni, hanem a végén, de akkor marha nehéz lesz átállni DTO-ra, ha eddig végig az entitásokat passzolgattuk a komponensek között.
Gondolom vannak érvek a model használata mellett is, de most nem jut eszembe ilyen, és biztosan jön valaki, aki arról is tud mesélni. Ja igen, az ORM is nyújthat megoldásokat az általam fentebb felvetett indokokra, csak nem ismerem annyira mélyen őket, hogy mindegyikre tudnék mondani valami dögös annotációt.
DTO-t használni nekem könnyebbség. Nagyobb rugalmasságot ad. Ha változik a model, nem feltétlenül kell a service rétegen keresztülverni a változásokat pl. -
"Konkrétan a hozzászólás melyik részét tartod bullshitnek és miért"
Azt, amit kérnek, hogy felmondjon a jelentkező a hr-esnek, mint a leckét az iskolában. Ez számomra a tudás hibás és teljesen felesleges visszakérdezése: fejből tudni és visszamondani az elméleti anyagot, még "ha álmodból keltenek is fel. " Az ilyen tudás megszerzése jön a "magolásból", és nem a gyakorlatból, vagy a rátermettségből. Ez alapján tuti nem a megfelelő és alkalmas embert fogják felvenni.
A tapasztalatom (20 aktív IT, + 10 év egyéb terület) az, hogy az elméleteket halmozó emberek aszok, akik a megbeszéléséken a szót viszik, az elveket hangoztatják és az időt rabolják, de a tényleges munkát már képtelenek elvégezni.
Az ilyen szintű elméleti alaptéziseket nem kell hangoztatni, hanem azoknak megfelelően kell dolgozni. Egy kovács se tudja fejből elsorolni, hogy mi a helyes kalapálás alapelmélete és hogy milyen rácsszerkezetű a vas...egy kovács alkalmazásakor se kell ilyeneket kérdezni ... Vagy egy anesztes orvosnál se kérdeznek az állásinterjún olyat, hogy miből, mennyit adagol a lumbális érzéstelenítésnél és azt milyen szempontok alapján dönti el.Hmm. Azt hiszem, te többet láttál bele a kérésbe, mint én.
Ha neked tennék fel a kérdést egy interjún, hogy szerinted milyen egy jó, minőségi java osztály implementációja, akkor mit válaszolnál?---
A felhozott példákat én egy lehelletnyit túlzónak tartom, a vas rácsszerkezetét inkább hasonlítanám mondjuk a gépi kódhoz, mintsem a kódminőség megítéléséhez. Az meg igazán örvendetes lenne, ha az IT iparban is olyan képzésük lenne az embereknek, mint orvosi fronton, mentoring, sokéves rezidenskedés, stb. Én se kérdezném meg tőle az adagolást, mert feltételezném, hogy pontosan tudja. Na meg a beteg halálozások száma is jó indikátora a hozzáértésnek. -
E.Kaufmann
veterán
-
E.Kaufmann
veterán
-
Ha javaból, vagy mysqlből eléred, akkor elsőnek nyers adatként áthúzod a dbf tartalmát az adatbázisodba, aztán ott már könnyedén tudsz belőle dolgozni.
Anno 10 éve én is így dolgoztam be dbf-t, de az eszközre már nem emlékszem (azt hiszem, mivel Ms-sql volt az adatbázis, annak a pont ilyen feladatokra való Dts eszközével dolgoztam)Köszi mindkettőtöknek
-
Aethelstone
addikt
Olyasmi lehet, hogy működik, használják, miközben a kód kiüríti a Vector-t, ami utána a kód másik része olvasna belőle és hibát dob - tehát, én azt mondom, ez programozói hiba: vagy nem kéne üríteni a Vectort, vagy az olvasáskor kéne figyelni, mert lehet jogosan üres, csak éppen kezelni kéne azt.
Nyilván. De akkor sem memory leak
Race condition -
Én a program fejlesztőjével, forgalmazójával venném fel a kapcsolatot: a mellékelt hiba annyi, hogy a program egy Vectorból (laikusan mondjuk listának) akarja elővenni az első elemet, de az a Vector (lista) üres, ezért mondja a hibaüzenet: NoSuchElementException.
Oka lehet hibás működés (valószínű előzőleg valami, valahol rakna elemeket ebbe a listába, de az nem történik meg), ami nincs rendesen kezelve, vagy egyszerűen programozó hiba. -
sarkanyolo2
őstag
-
Aethelstone
addikt
-
Hűha. Ott elakadnék, hogy hirtelen nem tudnám mik is azok a Fibonacci-számok.
Komolyan, ez a lényeg a programozásban? Értem én, hogy maga a rekurzió fontos dolog, magam is használom, ha a feladat megoldása megkívánja. Azt is értem, Fibonacci-számoknak nagy a jelentősége, de mégis miért kell eldugni az egészet, egy teljesen életidegen kierőszakolt feladat mögé eldugni - Magyarországon hány valós üzleti problémát oldottak meg a Fibonacci-számok segítségével? Tehát, rekurzióra is vannak egyéb és az üzleti világhoz közelebbi példák.
De lehet, én vagyok ilyen furcsa (?) Én azt vizsgálnám, hogy mennyire tudja összekötni az üzleti igényt az adott eszközzel, programnyelvvel. Mennyire képes egy üzleti specifikációból valós és jól működő kódot alkotni. Olyat, amit később is könnyű továbbfejleszteni, alakítani. Nem azt keresném, hogy tudja-e a Fibonacci-mibenlétét. (hacsak nem valami tudományos projektre keresek fejlesztőt) -
Hűha. Ott elakadnék, hogy hirtelen nem tudnám mik is azok a Fibonacci-számok.
Komolyan, ez a lényeg a programozásban? Értem én, hogy maga a rekurzió fontos dolog, magam is használom, ha a feladat megoldása megkívánja. Azt is értem, Fibonacci-számoknak nagy a jelentősége, de mégis miért kell eldugni az egészet, egy teljesen életidegen kierőszakolt feladat mögé eldugni - Magyarországon hány valós üzleti problémát oldottak meg a Fibonacci-számok segítségével? Tehát, rekurzióra is vannak egyéb és az üzleti világhoz közelebbi példák.
De lehet, én vagyok ilyen furcsa (?) Én azt vizsgálnám, hogy mennyire tudja összekötni az üzleti igényt az adott eszközzel, programnyelvvel. Mennyire képes egy üzleti specifikációból valós és jól működő kódot alkotni. Olyat, amit később is könnyű továbbfejleszteni, alakítani. Nem azt keresném, hogy tudja-e a Fibonacci-mibenlétét. (hacsak nem valami tudományos projektre keresek fejlesztőt) -
Nem tudom milyen az a feladatsor, de ha az van benne, hogy készítsen ilyen-olyan láncolt listát, akkor az hülyeség.
Én még egyik üzleti partnerünktől se kaptam ilyen igényt az elmúlt húsz évben.
Szóval, valami egyszerű, de életszagú dolog kell, esetleg egy már előfordult üzleti igény fejlesztői specifikációja. -
MasterMark
titán
-
Falra másznék az ilyen "szintetikus" felvételi teszttől.
Ez kb annyit mond el delikvensről, mint egy Antutu teszt egy mobiltelóról.Én elbuknék a magam 15 éves aktív kódolási és 25 éves informatikai előéletével együtt a Fibonacci és a palindrom fogalmaknál. Fibonaccival utoljára talán 20 éve találkoztam, ha jól emlékszem...
(mondjuk egy javas for ciklus írását is csak a codeassist segítségével tudom elkezdeni
) -
Falra másznék az ilyen "szintetikus" felvételi teszttől.
Ez kb annyit mond el delikvensről, mint egy Antutu teszt egy mobiltelóról.Én elbuknék a magam 15 éves aktív kódolási és 25 éves informatikai előéletével együtt a Fibonacci és a palindrom fogalmaknál. Fibonaccival utoljára talán 20 éve találkoztam, ha jól emlékszem...
(mondjuk egy javas for ciklus írását is csak a codeassist segítségével tudom elkezdeni
) -
Jó, hogy mindenre van valami elnevezés, ami miatt az a valami marha különleges dolognak tűnik.
Fésüs lista. Dinamikus mátrix. Első hallásra már megijedek, pedig 10 éve Javazom.
Én egyszerűen egy listát látok, amibe listákat tárolnak. Ezen meg nem csodálkozom, hiszen tudom, hogy listába bármit belerakhatok, ahogy a működés megkívánja. És eszembe se jut mindegyikhez külön nevet keresni. Pl ennek mi a neve List<Map<String>> ?Ennek compile time error a neve.
-
Jó, hogy mindenre van valami elnevezés, ami miatt az a valami marha különleges dolognak tűnik.
Fésüs lista. Dinamikus mátrix. Első hallásra már megijedek, pedig 10 éve Javazom.
Én egyszerűen egy listát látok, amibe listákat tárolnak. Ezen meg nem csodálkozom, hiszen tudom, hogy listába bármit belerakhatok, ahogy a működés megkívánja. És eszembe se jut mindegyikhez külön nevet keresni. Pl ennek mi a neve List<Map<String>> ?Házi feladatban ezt használtam, és megjegyzésben minden metódushoz írni kell pár szót, végül mátrix maradt.
Köszön mindenkinek a választ. -
Jó, hogy mindenre van valami elnevezés, ami miatt az a valami marha különleges dolognak tűnik.
Fésüs lista. Dinamikus mátrix. Első hallásra már megijedek, pedig 10 éve Javazom.
Én egyszerűen egy listát látok, amibe listákat tárolnak. Ezen meg nem csodálkozom, hiszen tudom, hogy listába bármit belerakhatok, ahogy a működés megkívánja. És eszembe se jut mindegyikhez külön nevet keresni. Pl ennek mi a neve List<Map<String>> ? -
Alapvetően annyi, hogy a Game osztályod import részéből kitörlöd a hibás hivatkozást: import java.awt.Window;
(ebből látszik, hogy rossz Window osztályt használ)
Mivel a saját Window osztályod azonos csomagban van az őt használó Game osztállyal, ezért nem is kell külön importálnod. Érdemes a jövőben egyedibb nevekkel illetni a saját osztályaidat . A Window név nagyon általános emiatt, könnyen félrecsúszhat az import és így egy egész más Window osztály kerülhet bele. Bár az Eclipse segít, mert a codeassist már a kód írásakor mutatja, hogy melyik Window-ról lesz szó és fel is ajánlja az összes ugyanolyan nevű osztályt, amiből ki lehet választani azt, amire valóban gondolsz.Nálad, az Eclipse-ben amúgy valahogy nincs minden korrekten összerakva, mert ezt a hibát megint, már a kód írásakor tudná jelezni neked - aláhúzná pirossal
Meg jó lenne ha végre rájönnének az oraclenél, hogy az import alias nem lenne hülyeség
-
bairyhalls
csendes tag
Alapvetően annyi, hogy a Game osztályod import részéből kitörlöd a hibás hivatkozást: import java.awt.Window;
(ebből látszik, hogy rossz Window osztályt használ)
Mivel a saját Window osztályod azonos csomagban van az őt használó Game osztállyal, ezért nem is kell külön importálnod. Érdemes a jövőben egyedibb nevekkel illetni a saját osztályaidat . A Window név nagyon általános emiatt, könnyen félrecsúszhat az import és így egy egész más Window osztály kerülhet bele. Bár az Eclipse segít, mert a codeassist már a kód írásakor mutatja, hogy melyik Window-ról lesz szó és fel is ajánlja az összes ugyanolyan nevű osztályt, amiből ki lehet választani azt, amire valóban gondolsz.Nálad, az Eclipse-ben amúgy valahogy nincs minden korrekten összerakva, mert ezt a hibát megint, már a kód írásakor tudná jelezni neked - aláhúzná pirossal
Hm nemtudom, ctrl+shift+o-val szoktam beimportalni a kello dolgokat, kézzel soha, és valamiért ezt is behuzta, koszi a helpet
-
bairyhalls
csendes tag
-
Egy jó programozó egy négy megás memóriadumpot egy perc alatt átnéz és értelmez.
Vérbeli informatikus pedig, Win95-öt használ IE 4.0-val. Tűzfal, vírusirtó és ilyen úri huncutságokkal nem él. Ez mind csak a gyáva nyápicok szokása.En csak azt mondom, hogy pusztan fura szokasoktol nem lesz az ember szar programozo.
-
Aethelstone
addikt
-
"Sajnos azonban a mai senior Java fejlesztő brigád 1.6-1.7(1.5??) környékén leragadt."
Mert ezek fejlesztők általában elő, működő és aktívan használt projekteken dolgoznak, amikbe hosszú évek üzleti tudása van berakva. És erre nagyon vigyáznak. Nem fognak Java verziót váltogatni, mert az megjelent.
A kísérletező kedvű ifjú titánok persze megtehetik, hogy mindenfélét kipróbálgassanak, de majd bekerülnek az "életbe" és örülnek, ha nem kell meglévő funkciókat vagy, projekteket piszkálgatni. -
Aethelstone
addikt
"Sajnos azonban a mai senior Java fejlesztő brigád 1.6-1.7(1.5??) környékén leragadt."
Mert ezek fejlesztők általában elő, működő és aktívan használt projekteken dolgoznak, amikbe hosszú évek üzleti tudása van berakva. És erre nagyon vigyáznak. Nem fognak Java verziót váltogatni, mert az megjelent.
A kísérletező kedvű ifjú titánok persze megtehetik, hogy mindenfélét kipróbálgassanak, de majd bekerülnek az "életbe" és örülnek, ha nem kell meglévő funkciókat vagy, projekteket piszkálgatni. -
szcsaba1994
tag
-
Ja persze. Azért annyira nem, hogy, azt mondjam tényleg őrült vagyok, ha manapság Eclipse-t használok. Ráadásul szabadon.
Kezdődhetne az "én IDE-m a legjobb merthogy" harc is ezzel, de mivel ezt már sok helyen eljátszották felesleges az ismétlés. Örüljünk, hogy van választék. (Amúgy eclipse forevör alap
) -
WonderCSabo
félisten
Pont erről beszélek. Lexikális tudásuk van, a kézikönyveket, tankönyveket bevágták a belőlük készült kvízkérdéseket tudják, de értelmesen megírni egy kódot nem tudnak.
A lexikai tudást, a pontos szintaktika ismereterét bármikor kiegészíthetem a lokális help, kézikönyv vagy a gugli segítségével. Ha az adott ismeretere sokszor van szükségem, akkor a harmadik eset után már készség szinten tudni fogom. Amúgy meg nem érdekel, mert nincs rá szükségem. Az én fejem nem káptalan.A hiányzó gondolkodást viszont nem lehet beszerezni semmilyen forrásból sem.
Ez alapján egy interjún adjanak egy frappáns kis feladatot, amit előre okosan kitaláltak. Ne szopatóst, hanem egy ésszerűen 30 perc alatt megoldhatót. Ja, hogy ezt az interjúztatónak előre ki kéne találni, ahhoz meg neki is gondolkodni kellene... Így tényleg egyszerűbb egy Java alapú "Legyen ön is milliomosból" összeollózni 20 kérdést.
-
WonderCSabo
félisten
Szomorú, hogy ilyen kvízkérdésekkel interjúztatnak.
Én több, mint 10 éve programozok (többnyire java, plsql). Ma sem tudnom fejből egy ciklus szintaktikáját. Ott a codeassist az megírja. Én meg megtöltöm tartalommal.
A láthatóságok listáját se magoltam be mégis ismerem, értem és használom őket, de ha kérdeznének biztos kihagynám valamelyiket. -
-
Aethelstone
addikt
Köszönöm példát, bár ott az egyik egy primitív, amelynél ugye alapból nincs értelme semmilyen függvény meghívásáról beszélni. A példádban amúgy outboxing történik, vagyis a Longból veszi ki automatikusan a longot és így már primitívek között persze, hogy csak a == működik.
Más. Látom csak nekiálltál alpári stílusban írni. Jelzem amiről beszélünk az nem offtopic, még akkor sem, ha te mindenképp azt hajtogatod, hogy én "kurvára szétoffolom". Sajnálom, ha egy szakmai topikban nem vagy képes megmaradni a szakmaiságon belül, sőt kifejezetten zavar téged.
-
Aethelstone
addikt
-
Aethelstone
addikt
"Az autoboxingos osztályoknál pl. szükségtelen az equals, mivel gyárilag meg van írva, hogy pl. a Long i-nél az i.longValue()-t hasonlítja a megadott longhoz....."
Ezt nem értem.Ha két Long-ot == jellel akarsz összehasonlítani, akkor megint csak a két referenciát vizsgálod. Amúgy persze, hogy a Long equals függvénye úgy gondolkodik, hogy a longValue()-t veti össze a a saját value mezőjével De ez nem az autoboxingból jön, hanem ez is ugyanaz a logika, mint amit már leírtam (ahogy a String-nél meg a saját value[]-ból dolgozik)."Persze, saját osztályoknál nyilván az equals a célszerű és a követendő, de itt konkrétan a String-ről volt szó és itt mindenképpen az equals kell."
Mindig equals kell, fogadd el!(#7362) Ursache
Mivel osztályokról beszélünk, ezért nem kell egyértelműsíteni, hogy csak a nem primitíveknél van így. Az osztály eleve NEM primitív. -
Aethelstone
addikt
"Java-ban a Stringeket equals-sal hasonlítunk össze, nem ==."
Ez kicsit sántít ill. félrevezető.
Java-ban a == -nal nem a két objektumot hasonlítjuk össze, hanem a két referenciát. Vagyis akkor kapunk igazat ha mindkettő ugyanarra az objektumpéldányra mutat.
Az equals-nél pedig meghívjuk az adott objektumpéldány equals függvényét, ami az objektumra jellemző összehasonlítást végzi és megmondja, hogy a paraméterként megadott másik objektumpéldányt azonosnak tekintjük-e, vagy sem. Ebben az equals-ben lehet megírni az objektumra jellemző logikát, ami az azonosságot kimondja. String-nél természetesen ezt már megírták és akkor mondja azonosnak, ha pontosan ugyanaz a a karakterliterál van mindkét String példányban.
De pl. írhatok az Alma osztályomba egy saját equals függvényt, ami az én logikám szerint akkor ad igazat ha a méret, a szín és a súly tulajdonságai megegyeznek a két összehasonlítandó Alma osztályból létrehozott példánynálTehát, NEM CSAK Stringnél kell az equals a == helyett az azonosság eldöntésére, hanem minden osztály példányánál.
Tehát, NEM CSAK Stringnél kell az equals a == helyett az azonosság eldöntésére, hanem minden osztály példányánál.
Nos, ez nem ilyen egyértelmű. Az autoboxingos osztályoknál pl. szükségtelen az equals, mivel gyárilag meg van írva, hogy pl. a Long i-nél az i.longValue()-t hasonlítja a megadott longhoz.....
Persze, saját osztályoknál nyilván az equals a célszerű és a követendő, de itt konkrétan a String-ről volt szó és itt mindenképpen az equals kell.
Pongyolán fogalmaztam, ez tény
-
"Java-ban a Stringeket equals-sal hasonlítunk össze, nem ==."
Ez kicsit sántít ill. félrevezető.
Java-ban a == -nal nem a két objektumot hasonlítjuk össze, hanem a két referenciát. Vagyis akkor kapunk igazat ha mindkettő ugyanarra az objektumpéldányra mutat.
Az equals-nél pedig meghívjuk az adott objektumpéldány equals függvényét, ami az objektumra jellemző összehasonlítást végzi és megmondja, hogy a paraméterként megadott másik objektumpéldányt azonosnak tekintjük-e, vagy sem. Ebben az equals-ben lehet megírni az objektumra jellemző logikát, ami az azonosságot kimondja. String-nél természetesen ezt már megírták és akkor mondja azonosnak, ha pontosan ugyanaz a a karakterliterál van mindkét String példányban.
De pl. írhatok az Alma osztályomba egy saját equals függvényt, ami az én logikám szerint akkor ad igazat ha a méret, a szín és a súly tulajdonságai megegyeznek a két összehasonlítandó Alma osztályból létrehozott példánynálTehát, NEM CSAK Stringnél kell az equals a == helyett az azonosság eldöntésére, hanem minden osztály példányánál.
-
Aethelstone
addikt
-
Aethelstone
addikt
-
Aethelstone
addikt
Az épitőipari iskolában a diákok két méter hosszú és egy méter magas téglafalakat építgetnek, majd elbontják azokat. Tök értelmetlen!
Mégis, milyen példákon tanuljanak a diákok? Egy mintapélda mégse lehet, egy nagyvállalati ügyviteli rendszer. Ezek a példák a gondolkodást és annak adott nyelven történő megvalósítását tanítjak, ez a konkrét példa is pont ilyen. Szépen látszik, hogy egy ciklus az egész, melynek magjában változók értékadása, majd azok következő ciklusbeli felhasználása történik. Szép, frappáns feladat.
-
Egy tankönyvet ritkán kell úgy olvasni, mint egy regényt. Ki lehet hagyni részeket, hiszen mindenkinek más szinten van a tudása és az is más, és más részekből tevődik össze.
Viszont, ha csak az elmúlt hónap ide beérkező kérdéseit elolvasod észre kell vedd mennyien, már a programozás alapjait sem értik, nem beszélve az Oop-ről. Nekik nagyon is kell ez a leegyszerüsített magyar nyelvezet, ami elmond mindent az elejéről.
Ez a könyv nem egy Java könyv, hanem egy programozás tankönyv a Javan keresztül. Ennek az elődja Turbo Pascal volt. No arra írhatnád, hogy elavult, bár abból is meg lehet tanulni programozni.
Az általad ajánlott könyv feltételezi az alap programozási dolgok ismeretét (cikkus, elágazás, stb, stb), ez nem. És még egy, az angolul van, ez meg magyar. Ettől függetlenűl jó könyv, magam is olvasgattam, anno. -
Aethelstone
addikt
-
Miért nem a szerző nevére kerestél??? Akkor, amikor azt is leírtuk, ne a "24 órás" könyvbőlj tanulj.
Szerintem félreértetted a dolgot...
Itt leírtad hogy melyik az a könyv,amit ajánlasz..
itt megköszöntem és reagáltam floatr hsz-ére
Ha nem erre gondolsz, akkor azért nem kerestem rá a szerzőre mert fogalmam sincs hogy kiírta azt a könyvet, aminek a nevét sem tudom -
Köszi, sikerült már beszerezni.
A fórumot tudom használni, csak nem tudtam, mit keresek ( 24 óra, könyv, illetve a kezdő szóra kerestem) A legtöbb találatot 200X. évben hozta a kereső,így inkább rákérdeztem
Bár nem értek a dologhoz, de elég felszínesnek éreztem a könyv leírását. Mivel hosszú távú terveim vannak vele így az elejétől, szájbarágósan akarom az egészet tanulni.
Köszönöm még egyszer a segítséget -
-
Sk8erPeter
nagyúr
-
Én tanultam a főiskolán programozást (elsőnek TurboPascal, aztán meg Java keretében - pont az Angster könyvet kaptuk), de az igaz javas ismereteimet később a munkahelyem napi gyakorlatban szereztem (illetve itt még elvégeztem a Sun által tartott tanfolyamokat), mivel itt bedobtak a mélyvízbe.
Természetesen autodidakta módon is eljuthatsz akármeddig. A legfontosabb, hogy csináld, ehhez viszont kellenek értelmes feladatok, amikben a megvalósítandó dolgokat nem alakítgathatod csak azért, mert a tudásodhoz képest kihívásokat állít eléd. Pont ezek azok amiket le kell küzdened, ki kell kaparnod a megoldást, utána kell olvasnod és kérdezősködnöd ill.,sokat-sokat kell próbálkoznod. Ettől okosodsz!
Köszi!
Na, igen, többek között ezért is szeretnék valakit találni, aki ezzel foglalkozik, és akivel kontrollált körülmények között tudok haladni. Eddig általában mind az Arduino (C++ alapú) programozása, mind a Java programozása során megtaláltam az adott nyelvben, az adott feladathoz szükséges megoldásokat, de fogalmam sincs, hogy azok a legjobb megoldások, vagy csak jó megoldások voltak-e, vagy esetleg "épp, hogy megoldások" voltak, de semennyire nem voltak pl. elegáns megoldások. Pl. pár hete leprogramoztam egy egyszerű számológépet Javaban, ami úgy működött, hogy a TextField, getText által adott értékeket alakította át ParseFloat utasítással, amelyekkel aztán matematikai műveleteket végzett, majd az eredményt ismét String-ként jelenítette meg a TextField-en. Mivel csak magamtól, innen-onnan szedegetem össze a tudásomat, ilyen - gondolom nem túl szerencsés - megoldásokat találok ki. Tehát az alapvető programozási szemléletet (vagy hogy is nevezzem) is meg kellene tanulnom. Ezt is el lehet sajátítani önállóan?(#6178) axioma:
Én is sokat merítek mások kódjából. Ha volt valami feladat, amire sehogy nem jöttem rá magamtól, megkerestem egy hasonlót a neten, és felhasználtam. Ha működött, átolvastam sokszor, memorizáltam, magamévá tettem, így legközelebb, hasonló esetben már tudom használni.Szóval, érzem én, hogy ma már szinte mindent meg lehet tanulni a neten elérhető anyagokból, csak szeretnék minél gyorsabban haladni.
-
Belenéztem. Botrányos!
Amikor azt mondja az elején, hogy a Java kvázi objektumorientált, akkor már megszédültem. Aztán amikor kifejtette, hogy "az objektumorientáltság azt jelenti, hogy osztályokat kell majd létrehoznunk" akkor már nagyon féltettem a kezdő, zöldfülű hallgatóságot. A "be fogom mutatni a Class Library néhány osztálykönyvtárát" elszólásnál már tudtam, ez nem tudja mit beszél, nem ismeri a szavak jelentését, nem tudja tudását átadni, egyszerűen alkalmatlan arra, hogy oktasson. (azon túl, hogy a sok nyökögésből, összevissza gondolatfoszlányokból nagyon nehéz bármilyen összefüggést kihámozni)
Annak, aki most ismerkedik a java-val és új neki az objektumorientáltság annak én az Angster féle Java könyvet ajánlom. Semmi fellengzős szakzsargon, nem akar mindjárt profinak látszani, lemegy a zöldfülűek szintjére és türelmesen elmeséli miről is van szó.
Az Angster-féle könyvek valóban jók. Az első könyv itt érhető el PDF-ben: Objektumorientált tervezés és programozás - Java 1
A második könyvet nem tették ki (még) ingyen, kapható is újonnan. (Bár találkoztam már szkennelt PDF-fel abból is)Szintén jók a Lynda.com féle anyagok, ezek videó tutorialok angolul, rengeteg témában, többek között jávában, több szinten, illetve magáról az objektumorientáltságról, a tervezésről is vannak videók. Az oldal fizetős (25$/hó), de megéri, ha ilyesmivel foglalkozol, azonban az anyagokba való betekintésre másutt is van mód.
Egyébként itt egy egyhetes ingyenes kipróbálási lehetőség, ha ezen keresztül regisztráltok Ja, nem fűződik hozzá anyagi érdekeltségem. 
-
WonderCSabo
félisten
-
Aethelstone
addikt
-
WonderCSabo
félisten
-
fordfairlane
veterán
-
Aethelstone
addikt
-
Aethelstone
addikt
-
WonderCSabo
félisten
-
WonderCSabo
félisten
Az is lehet, a felvetésedet nem értem teljesen. (mobilról vagyok, kódokat nem írnék most ;-) )
Most látom, hogy nem csak új példány esetén akarod az inkrementálót meghívni, hanem mindig. (Mondjuk ezt nem értem miért jó, de biztos van oka. Mi van, ha close nélkül valaki újra elkéri a példányt?). Így viszont hirtelen én sem látok más megoldást (ha mindegyik db kezelő leszármazott külön saját kezelővel akar rendelkezni)
-
WonderCSabo
félisten
Ezt a nyitó-záró logikát tedd egy külön statikus függvénybe, bemenő paraméterként az ős db kezelővel, melynek konstruktora hívja meg a statikus nyitó-záró függvényt, önmagát átadva neki.
Ugyanígy járj el a close-zal is.
Természetesen a db kezelőid továbbra is singletonként példányosítsd!Ez nekem nem világos.
Leírnád mire gondolsz (akár kvázi peszudókóddal) ? -
WonderCSabo
félisten
-
WonderCSabo
félisten
Például, ha magában a forráskódban akarják valamiért tagolni a szöveget. Pl:
String vers;
vers = "Este van, este van: kiki nyúgalomba!\n" +
"Feketén bólingat az eperfa lombja,\n" +
"Zúg az éji bogár, nekimegy a falnak,\n" +
"Nagyot koppan akkor, azután elhallgat.";System.out.println(vers);
-
Még oda is írja a magyarázatba, hogy
"One interface might extended another interface, but a class cannot extend an interface"
és akkor megjelöli a D-t helyesnek, ahol meg:public CLASS Test EXTENDS SampleCloseable {
Public void close () throws java.IO.IOException {
// do something
}tehát, a D tuti hibás!
-
"Valamiért nekem még mindig az volt a fejemben, hogy az equals nullptr-t dob akkor is, ha a paraméter null."
Általában elmondható az equals-re is, hogy úgy működik, ahogy megírták és azt dobja, amit nem kezeltek benne, vagy amit szándékosan dobnak.
Amúgy, a legősibb equals az Objectben van, ami nem dob null-t null bemenő esetén, csak kiad egy szép false-t.
Rengetegszer takarítottam már hasonlót mások után, emiatt világított egyből a dolog. De még mindig úgy emlékszem, ha most már rendben is van az equals, hogy régebben nem volt annyira nullptr-mentes. Szori mindenki, vaklárma volt
-
Azért a generics használata, főleg keretrendszereknél hasznos tud lenni. Pl.: egy rakat instanceof vizsgálattól kímél meg, viszont sokszor nagyon megnehezíti magának a generics-es kódoknak a karbantartását: nagyobb osztályhierarchián átívelő generics-ek módosításakor (pl: újak bevezetése) eléggé nehézkes az átírás, refaktor.
-
Tudni kell, hogy ez nem elegáns megoldás (persze sokszor rákényszerül a kódoló ember az ilyen "csúnyaságokra")
A java-ban a kivételeket kezelni kell a try-catch-finally blokkal, de dobhatjuk tovább is, amit jelezni kötelező a függvény szignatúrájában. (ezzel tk. továbbadjuk a hívó félnek a kezelés felelősségét) Kivétel ez alól a RuntimeException és annak kiterjesztései. Hogy miért e kivétel? Álljon itt egy idézet a Java Programming Language (SL-275) tankönyvből
"RuntimeException indicates a design or implementation
problem. That is, it indicates conditions that should never happen
if the program is operating properly. Because a correctly designed and
implemented program never issues this type of exception, it is
usual to leave it unhandled. This results in a message at runtime,
and ensures that action is taken to correct the problem, rather than
hiding it where (you think) no one will notice."(megsúgom én is használok RuntimeException-ből származtatott saját kivételeket, de a keretrendszerem globálisan lekezeli őket, ellenben megspórolom, hogy állandóan foglalkozzak a függvényeimben a throw-szal)
Vannak teoretikusok, akik mindenbe belekötnek, amikor megírják a könyveiket. Az ellenőrzött kivételek a saját kódodat erősítik, közvetlen megoldásokkal. A RuntimeException származékok pedig pl. egy konténert címeznek meg valami fatális tévedéssel. Az egyik legjobb példa erre, amikor SOA backended van, és központosított hibakezeléssel akarsz kommunikálni a kliens felé. A nagyobb problémákat egyszerűen nem lehet vagy nem éri meg ellenőrzött kivételekkel visszavezetni, amikor a konténer ezt automatikusan elvégzi egy kis testreszabással.
De ha már itt tartunk, akkor a generics inkább egy baromi nagy tervezési hiányosság, mint ez
-
Szerintem, nem.
Gyárilag csak olyanok vannak ott, amiket valóban kerülnénk programunk futásakor. Ezek a kivételek szinte bármelyik programsornál előfordulhatnak, míg a többi csak jól behatárolható helyeken (pl. IOException) De persze megint tudom a kivételt is, hisz sokszor tudatosan használjuk őket. Pl. egy többszöri if (x == null) vizsgálat helyett hagyjuk, hogy beszaladjon a NullpointerException-be, ami majd egy alkalmas helyen elkapunk és kezelünk.
És azt se feledjük, ezek a magyarázatok csak próbálják leírni az egész kivételkezelést!mindneki olyan checked exceptionökkel rakja tele a kódját, amilyenekkel akarja. Csak ne nekem kelljen rajta dolgoznom
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Mibe tegyem a megtakarításaimat?
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Genshin Impact (PC, PS4, Android, iOS)
- Elektromos (hálózati és akkus) kéziszerszámok, tapasztalatok/vásárlás
- gban: Ingyen kellene, de tegnapra
- Mobilinternet
- Óra topik
- Xbox tulajok OFF topicja
- Feltalálta a Google a keresőmotort
- Jövedelem
- További aktív témák...
- Nintendo Switch OLED 64GB+256GB MicroSD + okositott, Atmosphere 3 hó garanciával
- Akciós! Kishibás! Macbook Pro 13 M1 16GB 256GB Akku: 87% 1 év garancia
- Macbook Pro 13 M1 16GB 256GB Akku: 88% 1 év garancia
- iPhone 17 Pro max 256GB kék bontatlan 1 év Apple jótállás
- OmniBook X Flip 14" 3K OLED érintő Ultra 7 258V 32GB 1TB NVMe IR kam gar
- LG UltraGear 27GR95QE-B 240 Hz OLED 2560x1440 Gamer Monitor 6 hó garancia Házhozszállítás
- MSI Gaming X Trio RTX 5080 // Számla // Garancia //
- Apple iPhone 13 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! 32GB G.Skill Trident Z Royal 4000Mhz DDR4 memória garanciával hibátlan működéssel
- Bomba ár! Lenovo ThinkPad X230 - i5-3GEN I 4GB I 320GB I 12,5" HD I Cam I Garancia!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest