Új hozzászólás Aktív témák

• Aethelstone addikt

  #6623

  #6622 beleszólok

  2014-11-29 15:54:26

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6622 beleszólok

  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

  #6602

  #6601 beleszólok

  2014-11-24 19:27:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  WonderCSabo

  félisten

  #6601 beleszólok

  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

  #6583

  #6579 beleszólok

  2014-11-24 11:02:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  WonderCSabo

  félisten

  #6579 beleszólok

  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

  #6582

  #6577 beleszólok

  2014-11-24 10:56:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6577 beleszólok

  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

  #6580

  #6577 beleszólok

  2014-11-24 10:53:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #6577 beleszólok

  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étre

  Ez 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

  #6578

  #6577 beleszólok

  2014-11-24 10:37:09

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  WonderCSabo

  félisten

  #6577 beleszólok

  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

  #6571

  #6566 beleszólok

  2014-11-23 19:19:53

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6566 beleszólok

  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

  #6570

  #6566 beleszólok

  2014-11-23 14:14:44

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #6566 beleszólok

  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

  #6569

  #6568 beleszólok

  2014-11-22 11:49:22

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  M_AND_Ms

  veterán

  #6568 beleszólok

  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

  #6567

  #6563 beleszólok

  2014-11-22 10:51:25

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Jim-Y

  veterán

  #6563 beleszólok

  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

• emvy félisten

  #6565

  #6560 beleszólok

  2014-11-22 10:23:44

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #6560 beleszólok

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

• emvy félisten

  #6564

  #6560 beleszólok

  2014-11-22 10:17:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #6560 beleszólok

  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

  #6561

  #6560 beleszólok

  2014-11-22 10:13:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  WonderCSabo

  félisten

  #6560 beleszólok

  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

  #6559

  #6558 beleszólok

  2014-11-22 10:08:27

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  WonderCSabo

  félisten

  #6558 beleszólok

  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.

• emvy félisten

  #6552

  #6550 beleszólok

  2014-11-21 08:56:50

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #6550 beleszólok

  > 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

  #6533

  #6529 beleszólok

  2014-11-20 12:43:53

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  #6529 beleszólok

  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

  #6532

  #6531 beleszólok

  2014-11-20 12:05:34

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6531 beleszólok

  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

  #6530

  #6529 beleszólok

  2014-11-20 11:57:23

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6529 beleszólok

  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.

• emvy félisten

  #6527

  #6526 beleszólok

  2014-11-20 11:32:54

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #6526 beleszólok

  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.

• emvy félisten

  #6524

  #6522 beleszólok

  2014-11-20 11:15:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #6522 beleszólok

  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.

• emvy félisten

  #6523

  #6521 beleszólok

  2014-11-20 11:11:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #6521 beleszólok

  Nem hivjak valtozonak, erteknek hivjak. Mindegy.

• emvy félisten

  #6520

  #6518 beleszólok

  2014-11-20 11:05:48

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #6518 beleszólok

  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

  #6508

  #6502 beleszólok

  2014-11-19 16:42:40

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6502 beleszólok

  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

  #6507

  #6505 beleszólok

  2014-11-19 16:27:33

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #6505 beleszólok

  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

  #6506

  #6505 beleszólok

  2014-11-19 14:12:51

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6505 beleszólok

  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

  #6504

  #6503 beleszólok

  2014-11-19 13:49:46

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #6503 beleszólok

  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

  #6499

  #6498 beleszólok

  2014-11-19 13:04:51

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6498 beleszólok

  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

  #6497

  #6496 beleszólok

  2014-11-19 12:37:11

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6496 beleszólok

  Most komolyan. Olvasd már el kérlek, amit írtam! Ugyanazt írtam, amit Te. Nomen est omen?

• Aethelstone addikt

  #6495

  #6494 beleszólok

  2014-11-19 12:20:29

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6494 beleszólok

  Olvasni, olvasni, olvasni!

  [link]

  Mielőtt nagyon átmegyünk kioktatóba....

• #39560925 törölt tag

  #6491

  #6490 beleszólok

  2014-11-19 10:46:53

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  #6490 beleszólok

  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

  #6487

  #6485 beleszólok

  2014-11-19 09:39:37

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #6485 beleszólok

  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

  #6486

  #6485 beleszólok

  2014-11-19 09:18:31

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #6485 beleszólok

  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

  #6481

  #6480 beleszólok

  2014-11-18 23:17:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #39560925

  törölt tag

  #6480 beleszólok

  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