- Teclast Tablet Topic
- 3DMark Vantage eredmények
- Milyen videókártyát?
- Everest / AIDA64 topik
- Melyik tápegységet vegyem?
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
Új hozzászólás Aktív témák
-
#6623
Aethelstone
addikt
beleszólok
#6622
Aethelstone
addikt
válasz
beleszólok
#6622
üzenetére
Itt egy cseppet másról van szó. Nevezetesen arról, hogy az enterprise java környezetekben a Bean-ek nem önmagukban álló entitások, hanem mindig egy interfész/egy vagy több implementáció szerepel és a dependency injection mindig interfészt injektál és nem konkrét implementációt. (Kivéve amikor több implementáció van, viszont ebben az esetben is interfészként hivatkozunk rá, de az injektáláskor megmondjuk nevesítve, hogy melyik implementációról van szó konkrétan @Resource("akarmi") pl.)
Ebben az esetben egy osztály attól függően hogy milyen interfész implementációjára hivatkozunk, máshogy viselkedik nyilván, tökre elrejti az egyéb funkcióit, amiket sima osztályként el tudnánk érni, de itt szándékosan nem akarunk.
Standalone környezetben nem szokták erőltetni az interfész/implementáció párost, de mint írtam, enterprise környezetben de facto szabvány. Azért de facto, mert elvileg lehet implementációt is injektálni(meg minden egyebet is), de nem szép. Ennyi.
-
#6602
WonderCSabo
félisten
beleszólok
#6601
WonderCSabo
félisten
válasz
beleszólok
#6601
üzenetére
Manual -> oracle hivatalos tutorial, vogella
Design patterns, sztem nagyon faszán összehasonlítja.
Singleton: igen, sokak szerint anti-pattern. Időnként hasznos lehet, de normálisan kell használni.
MVC, ez is egy pattern végülis.
Decorator: ugye itt egy speckó python nyelvi elemről van szó. A műkődése viszont tényleg kvázi a pattern, viszont a python-os cucc függvényt dekorál, a design pattern pedig objektumot/osztályt.
-
#6583
WonderCSabo
félisten
beleszólok
#6579
WonderCSabo
félisten
válasz
beleszólok
#6579
üzenetére
Kicsit hosszú lenne itt részletezni (mást ne mondjak: tömböt gyárthatok elemi típusokból is, egyebeket csak objektumokból)
Fú, ne keverjük a szezont a fazonnal. Ennek a dolognak, amit említettél, nem sok köze van magához a listához és a tömbhöz, ez a Java (nagyon sokak szerint elcseszett) generikus működése miatt van.
Egyébként a python list, és a Java ArrayList ugyanaz, csak más szintaktikával tudod elérni a műveleteit.
-
#6582
Aethelstone
addikt
beleszólok
#6577
Aethelstone
addikt
válasz
beleszólok
#6577
üzenetére
Kicsit a "kőkorban" érzem magam miatta, amikor még PL/I-ben, Clipperben programozgattam.
Rossz a megközelítés. Akkor lennél a kőkorban, ha a tömböt hákolták volna meg dinamikussá. Egészen egyszerűen újabb adattípusokat vezettek be, amik már máshogy kezelendpk, mint a tömb. Ennyi.
-
#6580
floatr
veterán
beleszólok
#6577
floatr
veterán
válasz
beleszólok
#6577
üzenetére
Amit nem látsz más nyelvekben az az, hogy hogyan van ténylegesen implementálva a "tömb". Javaban az ArrayList és tsai alacsony szintig követhetően implementált dinamikus tömb. Hogy most beírhatsz-e olyat, hogy list[2578] = "foo"; az egy dolog, a hátterében működhet sokminden:
-- pl operátor overloading, ami egy saját metódust hív, amikor [] operátort talál
-- egy automatikus memóriafoglalás a háttérben 2578 + buffer méretig
-- máshol egy hash-alapú map jön létreEz az egész rajtad áll vagy bukik, de elvárni sok automatizmust a nyelvtől azt fogja eredményezni, hogy vagy a fordító, vagy a végrehajtás lassú lesz. Az meg a másik, hogy sok értelmét nem látom egy ilyen műveletnek, bár lehetnek specifikus esetek nyilván; ide specifikus ötletek kellenek, pl. treemap.
-
#6578
WonderCSabo
félisten
beleszólok
#6577
WonderCSabo
félisten
válasz
beleszólok
#6577
üzenetére
viszont engem pusztán az zavar, hogy nincs olyan tömb, amihez utólag, másolás nélkül tudnék hozzáadni újabb elemeket
Én ezt most már nem értem...
Egyébként meg ArrayList és nem ListArray.
-
#6571
Aethelstone
addikt
beleszólok
#6566
Aethelstone
addikt
válasz
beleszólok
#6566
üzenetére
Nem összehasonlítható. Az egyik tömb, a másik pedig egy collection egy elemére hivatkozás. Teljesen más tészta a két történet.
-
#6570
floatr
veterán
beleszólok
#6566
floatr
veterán
válasz
beleszólok
#6566
üzenetére
Ez is csak szépészeti beavatkozás lenne, hogy operátor vagy metódus. Az mondjuk tény, hogy c++ alatt ott kezdődik a probléma, hogy a new is operátor, amit át lehet definiálni. Mondjuk én nem kuporodtam miatta sírva a sarokba, mert a java-féle heap-kezelést lehetett vele utánozni osztály - pointer osztály párosokkal, de részletkérdés, hogy a[5] vagy a.get(5). Iterátorokat többet használja az ember, nekem sem rémlik h mikor címeztem direktbe pozíciót utoljára.
-
#6569
M_AND_Ms
veterán
beleszólok
#6568
M_AND_Ms
veterán
válasz
beleszólok
#6568
üzenetére
Csak a stackoverflow-nak nem ez célja. Problémákra a megoldást hozza, nem pedig a terjedelmes elméleti fejtegetéseket.
-
#6567
Jim-Y
veterán
beleszólok
#6563
Jim-Y
veterán
válasz
beleszólok
#6563
üzenetére
A stack szerintem alapvetően arra jó, hogy ha valahol elakadsz, akkor több mint valószínű, hogy találsz rá megoldást az oldalon, de ha csak + információt szeretnél felvenni, akkor nem a megfelelő platform. Pont amiatt amit írtál. Én ha bővíteni szeretném a spektrumom, akkor redditre és twiterre járok, itt megnyitom az érdekes linkeket és ezek alatt sokszor lehet is beszélgetni a kommentekben, és nem zárják be azzal, hogy offtopik
-
#6565
emvy
félisten
beleszólok
#6560
válasz
beleszólok
#6560
üzenetére
Az ArrayList az pont az, mint amit a dynamic array Pythonban, szoval ne szomorkodj tul sokat. Ugyanugy amortizalt O(1) az append, O(N) az insert, es O(1) az index..
-
#6564
emvy
félisten
beleszólok
#6560
válasz
beleszólok
#6560
üzenetére
A Scala sokkal fiatalabb nyelv. Egyébként terjed rendesen, a pénzügyi szférában már tolják rendesen. A compiler elég lassú még, a nyelv meg eleg nagy (komplex).
-
#6561
WonderCSabo
félisten
beleszólok
#6560
WonderCSabo
félisten
válasz
beleszólok
#6560
üzenetére
Igen, pythonban is van operátortúlterhelés. Javában nincs, hogy miért az itt olvasható. A Java kritikájának egyik első eleme az operátortúlterhelés hiánya.
-
#6559
WonderCSabo
félisten
beleszólok
#6558
WonderCSabo
félisten
válasz
beleszólok
#6558
üzenetére
Javában egy féle tömb van:
String[] array = new String[20]
Ennek futásidőben lehet méretet adni, szóval a C++ -os dinamikus memória lefoglalású tömbbel analóg. Ennek a mérete fix, és van indexelő operátora. Vannak osztályok, amik ezt a tömböt felhasználva változtatható méretű listát implementálnak, pl. ilyen az ArrayList. Valóban csak metódusokkal lehet elérni az elemeit, de ennek az oka alapvetően az, hogy Javában nincs operátortúlterhelés.
-
#6552
emvy
félisten
beleszólok
#6550
válasz
beleszólok
#6550
üzenetére
> RAM-ból 16G azt hiszem, mostanság már majdhogynem alap.
Ja, csak a nyomorult gyartok nem raknak ennyit a gepekbe.
-
#6533
fordfairlane
veterán
beleszólok
#6529
fordfairlane
veterán
válasz
beleszólok
#6529
üzenetére
Szerintem a main-be tett publikus változó, az nagyjából megfelel a globális változónak, de OK, valóban, a javanak nincs olyan nyelvi konstrukciója, ami valódi globálist valósítana meg.
Egy public static változó vagy metódus szerintem tekinthető globálisnak.
-
#6532
Aethelstone
addikt
beleszólok
#6531
Aethelstone
addikt
válasz
beleszólok
#6531
üzenetére
Ha már nekem tudtál stackoverflow linket adni, akkor magadnak is kereshetnél.
http://stackoverflow.com/questions/4646577/global-variables-in-java
-
#6530
Aethelstone
addikt
beleszólok
#6529
Aethelstone
addikt
válasz
beleszólok
#6529
üzenetére
Nos, bármelyik osztályban található public változó (property, adattag, kinek hogy tetszik) globálisnak tekinthető. Az más kérdés, hogy ha nem muszáj, márpedig sosem muszáj, nem definiálunk public változókat. Szerintem.
-
#6527
emvy
félisten
beleszólok
#6526
válasz
beleszólok
#6526
üzenetére
Java-ban nincs igazabol globalis valtozo, talan a szingleton all hozza legkozelebb, de neked meg erre sincs szukseged. A main-t tartalmazo osztalyodban legyen egy publikus AtomicInteger, aztan kesz.
Bar tuti jon valaki, aki elmondja, hogy dependency injectionnel lesz igazi enterprajz megoldas
Masik kerdesedre: az int az tuti atomic, a long az vagy atomic, vagy nem. Az int 32 bites, a long 64, a VM implementacionak garantalnia kell az intek atomikus irasat/olvasasat, a longoket nem. Belemehetunk abba, hogy ez miert van -- elsosorban azert, mert 32 bites architekturakon a 64 bites ertekek atomikus irasa teljesitmenyvesztessel jar.
-
#6524
emvy
félisten
beleszólok
#6522
válasz
beleszólok
#6522
üzenetére
Ez konkretan ugy nez ki, hogy van egy concurrentlinkedqueue, amibe a file reader tolja a sorokat, a masik oldalon meg van egy executorservice thread pool, ami szedegeti ki az elemeket, es egy AtomicInteger novelgetsz.
Ez kb. a Concurrency 101 elso hetenek consumer-producer peldaja egyebkent.
-
#6523
emvy
félisten
beleszólok
#6521
válasz
beleszólok
#6521
üzenetére
Nem hivjak valtozonak, erteknek hivjak. Mindegy.
-
#6520
emvy
félisten
beleszólok
#6518
válasz
beleszólok
#6518
üzenetére
Hat, attol fugg, hogy es mit akarsz kommunikalni, szinkron vagy aszinkron, etc. Ott vannak pl. a ConcurrencCollection-ok, de akar hasznalhatsz sima osztott referenciakat is alapveto szinkronizacios mechanizmusokkal (lock, condition, stb.) -- mindegyik problemas, mas-mas szinten..
-
#6508
Aethelstone
addikt
beleszólok
#6502
Aethelstone
addikt
válasz
beleszólok
#6502
üzenetére
Rossz a példa. A goto az ördög találmánya olyan nyelvekben, amelyekben lehet mellőzni a használatát. Ahol viszont nem lehet, ott jó. Ennyi.
-
#6507
floatr
veterán
beleszólok
#6505
floatr
veterán
válasz
beleszólok
#6505
üzenetére
Nem javasolta, mert felülcsaphatná a start metódust, te meg nem javasoltad mert felülcsaphatná a start metódust. Most hogy mondod, télleg lehet h van gyakorlati jelentősége...
-
#6506
Aethelstone
addikt
beleszólok
#6505
Aethelstone
addikt
válasz
beleszólok
#6505
üzenetére
Csak ismételni tudom magam. Nomen est omen...ha érted, hogy mire gondolok.
Arra próbáltam utalni, mégha nem is fejtettem ki az ominózus hozzászólásban, hogy alapvetően nem kérdés, de egyesek képesek vallási kérdést csinálni belőle, pont úgy, mint a politikából vagy a fociból. (Pedig csak az Arsenal
)Kb. 2 hozzászólással utána kifejtettem pontosan, hogy mire gondolok, de Te azt ignoráltad és azóta is ezen lovagolsz. Részemről zártam.
-
#6504
floatr
veterán
beleszólok
#6503
floatr
veterán
válasz
beleszólok
#6503
üzenetére
Ha olyan feladatod lenne, ami miatt a Thread-be kellene piszkálni, akkor nem java-ban kell implementálni. Nem is értem h miért nem final az osztály. Illetve értem ("that would break backward compatibility"), mert a legelső könyvek tele voltak Thread subclass-okkal.
A vitával kapcsolatban meg azért mondom h kötekedés, mert ugyanarról beszélt, mint te
-
#6499
Aethelstone
addikt
beleszólok
#6498
Aethelstone
addikt
válasz
beleszólok
#6498
üzenetére
Lehet hitvita, mivel alapvetően a feladat határozza meg, hogy melyiket kell vagy érdemes használni, de ad abszurdum az is lehet, hogy mindkettő jó tud lenni. A programozásban sincsenek kizárólagos igazságok.
-
#6497
Aethelstone
addikt
beleszólok
#6496
Aethelstone
addikt
válasz
beleszólok
#6496
üzenetére
Most komolyan. Olvasd már el kérlek, amit írtam! Ugyanazt írtam, amit Te. Nomen est omen?
-
#6495
Aethelstone
addikt
beleszólok
#6494
Aethelstone
addikt
válasz
beleszólok
#6494
üzenetére
-
#6491
Oppenheimer
nagyúr
beleszólok
#6490
Oppenheimer
nagyúr
válasz
beleszólok
#6490
üzenetére
Ettől nem kell tartani.
A programban egy keresőalgoritmus implementálása és tesztelése volt a lényeg egyébként is. -
#6487
floatr
veterán
beleszólok
#6485
floatr
veterán
válasz
beleszólok
#6485
üzenetére
Mert nem szálat akarsz létrehozni, hanem egy futtatható feladatot. A szálnak saját állapotai vannak, amihez a feladatnak semmi köze sincsen, ráadásul tervezési mintának is elég törékeny
-
#6486
Aethelstone
addikt
beleszólok
#6485
Aethelstone
addikt
válasz
beleszólok
#6485
üzenetére
Igazából max annyi, hogy én speciel csak akkor használom a származtatást, amikor a szülő osztálynak valóban felül akarom valami tulajdonságát, metódusát definiálni vagy szeretnék default implementációkat használni a szülőből. A Thread run metódus szerintem nem ilyen történet.
Plusz, inkább implements mint extends
-
#6481
Oppenheimer
nagyúr
beleszólok
#6480
Oppenheimer
nagyúr
válasz
beleszólok
#6480
üzenetére
Próbáltam azt is, hogy létrehozok egy akármilyen intet, utána incrementálom és oda rakom a breakpointot, mert ott mindenképp meg kell állnia. Mindezt a numberOfStays előtt. Megpróbálom azt is amit mondasz.
Most megállt a breakpointnál, simán user error volt. F8-at nyomtam F9 helyett.
(IntellijIdea)
)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Szinte új állapotú Samsung Galaxy A54 5G 6/128GB
- Apple iPhone 13Pro 128GB Kártyafüggetlen 1Év Garanciával
- Garmin Fenix 8 Amoled 51mm Sapphire Carbon Gray DLC - Használt, karcmentes
- Nitro ANV15-51 15.6" FHD IPS i5-13420H RTX 4050 16GB 512GB NVMe magyar vbill ujjlolv gar
- Apple iPhone SE 2020 64GB Kártyafüggetlen 1Év Garanciával
- ÁRGARANCIA! Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Zebra ZP505 EPL - Hőpapíros címkenyomtató
- Bomba ár! Lenovo ThinkPad T460 - i5-6GEN I 8GB I 256SSD I 14" FHD I Cam I W10 I Garancia!
- Intel X540-T2 dual-port 10GbE RJ45 hálózati vezérlő (10Gbit, 2 port, áfás számla, garancia)
- AKCIÓ! Épített KomPhone R5 4500 16GB RAM 240GB SSD RX 6500 XT 4GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged