Hirdetés
- Motorola Edge 70 - többért kevesebbet
- Honor Magic6 Pro - kör közepén számok
- Örömhír: nem spórol Európán a OnePlus
- Yettel topik
- Xiaomi 15 - kicsi telefon nagy energiával
- iPhone topik
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Samsung Galaxy S4 - negyedik, bővített kiadás
- Olyan lesz a Google Térkép, mint a segítőkész haver az anyósülésen
- Az eddigieknél részletesebb videón a Samsung harmonikamobilja
Új hozzászólás Aktív témák
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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

-
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..
-
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).
-
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.
-
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.
-
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.

-
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.
-
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
-
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.
-
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.
-
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.
-
válasz
beleszólok
#6521
üzenetére
Nem hivjak valtozonak, erteknek hivjak. Mindegy.
-
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..
-
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.
-
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...
-
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.
-
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
-
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.
-
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?
-
Aethelstone
addikt
válasz
beleszólok
#6494
üzenetére
-
#39560925
törölt tag
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. -
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
-
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

-
#39560925
törölt tag
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
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- REFURBISHED és ÚJ - Lenovo ThinkPad 40AS USB-C Dock Gen2 (akár 3x4K felbontás)
- FELVÁSÁRLÁS A GYŐRÚJBARÁTI BOLTUNKBAN!
- NVIDIA RTX 4090 24GB HP OEM verzió (kiváló állapotban)
- Bomba ár! HP EliteBook 840 G7 - i7-10510U I 16GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Gari!
- Bomba ár! Lenovo ThinkPad T450s - i5-5GEN I 8GB I 240GB SSD I 14" HD+/FHD I Cam I W10 I Garancia!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest



)


