Hirdetés
- Messze nyolcezer fölött!
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Bejött a dupla megjelenítő a Lavanak
- iPhone topik
- Fontos frissítés érkezik a OnePlus 13-ra
- Honor Magic8 Lite - a félig sikerült bűvésztrükk
- Poco F8 Ultra – forrónaci
- Motorola Edge 60 Fusion - nem csak a forma időtálló
- Tiltott lett Lufthansa-csoport repülőin power bankot használni
- Bemutatkozott a Poco X7 és X7 Pro
Új hozzászólás Aktív témák
-
-
#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.
-
#6361
M_AND_Ms
veterán
WonderCSabo
#6360
M_AND_Ms
veterán
válasz
WonderCSabo
#6360
üzenetére
Pontosan!
-
M_AND_Ms
veterán
"Nézem ezt az Angster féle könyvet, mennyire gáz hogy kb 11 éves már? Érdemes ebből elkezdenem tanulni a 0-ról?"
Az objektumorientált szemlélet 11 évvel ezelőtt is ugyanaz volt, mint ma. A javaban a String se változott azóta. Jól is néznénk ki, ha 11 év alatt az alap dolgok érvényüket vesztették volna. Persze, ma már fogsz korszerűbb(nek kikiáltott) technológiákat találni bizonyos problémákra, de ha majd azokba belenézel akkor rájössz, azok is csak az örök érvényű alap dolgokból építkeznek. Csak megírták helyetted a frappáns megoldást az adott problémára.
Én a relációs adatbázisokról minden alap dolgot az 1978-ban kiadott Halassy féle könyvből tanultam.. Ott volt leírva jól és érthetően az összes dolog. Még az államvizsgára is ebből készültem eben a témában (2003-ban)
-
M_AND_Ms
veterán
válasz
sunnysys
#6175
üzenetére
É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!
-
M_AND_Ms
veterán
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ó.
-
#6130
M_AND_Ms
veterán
WonderCSabo
#6128
M_AND_Ms
veterán
válasz
WonderCSabo
#6128
üzenetére
Ez továbbra is int-t fog visszaadni. Legalábbis azt szándékozik.
-
#6125
M_AND_Ms
veterán
PumpkinSeed
#6124
M_AND_Ms
veterán
válasz
PumpkinSeed
#6124
üzenetére
static String input(){....
-
M_AND_Ms
veterán
válasz
plaschil
#6103
üzenetére
Az egyes bean-ekben azokat a private final mezőket, amiknek nem kívülről adsz értéket, nyugodtan teheted static-ba is. Ha pl száz példányt készítesz egy ilyen bean-ből, akkor ezek a mezők is százszor fognak létrejönni, inicializálódni, százszor foglalják a helyet a memóriában, miközben sohasem változnak és mindegyik bean-ben ugyanazt az értéket képviselik. Static esetén csak egyszer történik minden.
Pl: private static final double HAZAI_KILEPESI = 70.99;Az érték visszaadó getterekben (pl: getPontKodErtek) lévő logikát, már a konstruktorba hajtsd végre. Ha százszor hívják meg az ilyen gettert, akkor százszor fog lefutni ez a logika és mindig ugyanazt fogja visszaadni. Tehát elég egyszer kiszámolni a konstruktorban, ahol beadod az ertek paramétert.
-
#5985
M_AND_Ms
veterán
Aethelstone
#5975
M_AND_Ms
veterán
válasz
Aethelstone
#5975
üzenetére
Én meg 5 éve GWT-zek, két nagy projekttel. Eddig nem kellett a js kódhoz nyúlni. Igaz, csúnya módon egy Sencha osztályba bele kellett piszkálnunk.
-
#5589
M_AND_Ms
veterán
Aethelstone
#5584
M_AND_Ms
veterán
válasz
Aethelstone
#5584
üzenetére
Csak a "miért a régi elavult dolgokat tanítják" témához szól
-
#5583
M_AND_Ms
veterán
Aethelstone
#5582
M_AND_Ms
veterán
válasz
Aethelstone
#5582
üzenetére
91-ben az elektroműszerész suliban elektroncsövekkel ment minden alapkapcsolás...
-
#5470
M_AND_Ms
veterán
kemkriszt98
#5463
M_AND_Ms
veterán
válasz
kemkriszt98
#5463
üzenetére
Amelyik Collection-t iterálod, abból nem szedegethetsz ki elemeket, hisz akkor már nem egyértelmű melyik lesz a következő elem.
-
#5302
M_AND_Ms
veterán
WonderCSabo
#5298
M_AND_Ms
veterán
válasz
WonderCSabo
#5298
üzenetére
Ezért írtam, hogy akkor már elvész a singleton jelleg (pl protected konstruktorral. - micsoda fertő!).
A minták ajánlott és bevált működések megoldásai, de nem szentírások. Véleményem szerint nyugodtan megírhatod "nem normálisan". Tk. kitaláltál egy újabb mintát. Gratula! ;-)
-
#5297
M_AND_Ms
veterán
WonderCSabo
#5296
M_AND_Ms
veterán
válasz
WonderCSabo
#5296
üzenetére
" Alapvetően a Singletonból nem is tudsz örökölni."
Örökölni tudsz, csak a singletonosságát nem. Mondjuk érthető, hisz az osztályszintű, static dolog.
-
#5270
M_AND_Ms
veterán
WonderCSabo
#5269
M_AND_Ms
veterán
válasz
WonderCSabo
#5269
üzenetére
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)
-
#5268
M_AND_Ms
veterán
WonderCSabo
#5267
M_AND_Ms
veterán
válasz
WonderCSabo
#5267
üzenetére
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! -
#5162
M_AND_Ms
veterán
WonderCSabo
#5148
M_AND_Ms
veterán
válasz
WonderCSabo
#5148
üzenetére
Bizony ez így van.
Engem többször megszívatott a Generics-szekkel. Megengedett olyat, amit a 'rendes' fordító hibára tett. -
#5083
M_AND_Ms
veterán
WonderCSabo
#5080
M_AND_Ms
veterán
válasz
WonderCSabo
#5080
üzenetére
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);
-
#5054
M_AND_Ms
veterán
MasterMark
#5053
M_AND_Ms
veterán
válasz
MasterMark
#5053
üzenetére
Helyes!
-
#5052
M_AND_Ms
veterán
MasterMark
#5047
M_AND_Ms
veterán
válasz
MasterMark
#5047
üzenetére
Kérdezted, hogy a toString mit csinál. Azt, amit az adott osztályban megírtak. Ha ilyet nem tettek, akkor az ősosztály, az Object toString függvénye fog lefutni, ami a példányról ír ki általánosságokat.
Néha írnak bele gyakorlatban is használható dolgokat, de túl nagy haszna nincs.
-
-
M_AND_Ms
veterán
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!
-
M_AND_Ms
veterán
"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.
-
M_AND_Ms
veterán
válasz
#39560925
#4800
üzenetére
Talán azért, mert egy tapasztalt java fejlesztő mögött sok év van már. Amikor kezdtek (2005 előtt), akkor már az Eclipse egy kiforrott ide volt, míg a Netbeans egy használhatatlan valami.
Ezt a hátrányt több éve (2006, 2007 körül) ledolgozta a Netbeans és remek eszközzé vált, de akik ez előtt kezdtek javazni, azok már az Eclipse-nél maradtak.
Egy jól belakott ide-t nehezen cseréli a fejlesztő. -
#4797
M_AND_Ms
veterán
WonderCSabo
#4795
M_AND_Ms
veterán
válasz
WonderCSabo
#4795
üzenetére
Mint minden ilyen feladvány, ez is teljesen elrugaszkodott a valóságtól.
Ez olyan, mintha az autószerelő vizsgán az a feladvány lenne, hogy a hűtővíz befolyt az üzemanyagtartályba, ahova előzőleg benzin helyett, ablakmosót töltöttek. A kérdés, ha az üzemanyagtartályból kivett folyadékkal átmossuk a légszűrőt és visszarakjuk azt, akkor elindul-e ez az autó. -
-
M_AND_Ms
veterán
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.
-
#4718
M_AND_Ms
veterán
WonderCSabo
#4717
M_AND_Ms
veterán
válasz
WonderCSabo
#4717
üzenetére
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! -
#4716
M_AND_Ms
veterán
WonderCSabo
#4713
M_AND_Ms
veterán
válasz
WonderCSabo
#4713
üzenetére
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)
-
M_AND_Ms
veterán
válasz
smallmer
#4701
üzenetére
Vagy egy már létező (a catch ágban elkapott) Exception-t dobsz tovább, vagy egy teljesen újat hozol létre és azt dobod vele.
Pl.:....
catch (Exception e) {
//Valamit csinál hiba esetén
DbHandler.transaction(DbHandler.TRANSACTION_OPERATION.ROLLBACK);
//és továbbdobja
throw e;
}if (result == null) {
//Létrehoz egy új hibát és azt dobja
throw new Exception("Nem található a rekord.");
} -
M_AND_Ms
veterán
Én eleve irtózom az ilyen "fejből" tudni kell dolgokat számonkéréstől. Az én gondolkodásmódom nem abból áll, hogy tényeket az agyamból előrángatok, hanem hogy gondolkozom, és az ehhez szükséges tárgyszerű tudást, meg az annak megfelelő helyről előveszem.
Annak ellenére, hogy lassan 20 éve az informatikában dolgozom és elég széles spektrumban végeztem feladatokat, -ebből az utóbbi 8 évben aktív java fejlesztőként-, valószínű elbuknék az ilyen kvízkérdéseken. (egy ciklus vázát, még ma is az Eclipse code-assist segítségével rakom össze).Szerinte ne aggódj! Ha junior, kezdő fejlesztőt keresnek akkor annak megfelelő kérdéseket fognak feltenni (pl.: pont a pár hozzászólással ezelőtt felmerül static kulcsszó jelentését).
-
-
M_AND_Ms
veterán
válasz
Spam123
#4557
üzenetére
A kiírásban egy belső névtelen osztályban használtad az everything -et.
Így akkor visszatérünk az eredeti kódodhoz és odarakjuk abba a blokkba az egész kiírást. (kérdés, hogy a help-et hol hozod létre, az nem látszik a kódban)Ennek csak annyi a hátránya, hogy a beolvsott szöveget nem tudod máshol felhasználni.
A kód: http://pastebin.com/RLmf5XHB
(elnézést, de mobilról vagyok, így kicsit nehézkes)
-
M_AND_Ms
veterán
válasz
Spam123
#4545
üzenetére
Az általad létrehozott final String everything csak abban a blokkban létezik, kijjebb már nem. Vagy ott rögvest felhasználod, vagy a String everything deklarációt kijjebb teszed, a legjobb az egész cucc elejére. De ne rakd final-ba, mert akkor nem tudsz neki értéket adni később, csak a deklaráció helyén!
Az értékadás rész maradhat ott, ahol most van:
everything = sb.toString();A felhasználás meg az egész kiolvasás végén:
JOptionPane.showMessageDialog( null, beolvasottstring,"Valami",JOptionPane.OK_CANCEL_OPTION) -
M_AND_Ms
veterán
Mondjuk elsőnek ezen rágd végig magad: [link]
Vagy az Ansgter Erszébet féle objektumorientált javás könyv (valaki itt pár napja leírta a pontos címét is)Azt, hogy miképp teszed magadévá a tudást, miképp szerzel némi gyakorlatot az nem szigorúan java kérdés. Általában egy gyakorlati tudásról elmondható, hogy úgy teszel szert rá, hogy csinálod, csinálod és csinálod. Persze jó, ha az elején van ami/aki vezeti a kezedet.
Jómagam, amikor a jelenlegi melóhelyemre kerültem nem javáztam semmit sem. Itt egy Java SE tanfolyamot végigültem, miközben már feladatokkal bombáztak. Azóta meg meg ebből élek úgy, hogy közben sok-sok új technikával, technológiával meg kellett ismerkednem. De ezek már mind specifikusan az adott feladathoz kapcsolódóan jöttek elő. Tehát itt már nincsenek konkrétumok. Mindent úgyse fogsz tudni magadévá tenni. De újra mondom, amit az SE tartalmaz abból szinte minden kell, akármerre mész is.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Messze nyolcezer fölött!
- Amlogic S905, S912 processzoros készülékek
- Hálózati / IP kamera
- Napelem
- Path of Exile 2
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Túra és kirándulás topic
- Kerékpárosok, bringások ide!
- Xiaomi 15T - reakció nélkül nincs egyensúly
- World of Tanks - MMO
- További aktív témák...
- Lenovo ThinkPad T570 / i5-6300u
- Lenovo 14 Yoga Slim6 WUXGA OLED Ryzen5 7540U 4.9Ghz 16GB DDR5 512GB SSD Radeon 740M Win11 Garancia
- THE BARISTA PRO - SAGE SES878BTR - 3 év garancia
- Lenovo Legion 5 17ACH6H - RTX 3060 Ryzen 7 17,3 144Hz frissen szervizelt
- Lenovo LOQ GAMING Laptop! Ryzen 7 250 / RTX 5060 / 16GB DDR5 / 1TB
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
- új akku Ár/ÉRTÉK BAJNOK! Dell Latitude 5330 i3-1215U 6magos! - 16GB 256GB 13.3" FHD 1 év garancia
- www.stylebolt.hu - Apple eszközök és tartozékok!
- GYÖNYÖRŰ iPhone 14 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3971, 94% Akkumulátor
- Apple iPad Air 5.Gen 64GB 100% (1év Garancia)
Állásajánlatok
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest