Új hozzászólás Aktív témák
-
M_AND_Ms
addikt
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.Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
válasz Oppenheimer #4541 üzenetére
A gameArea null ez a baj. Mikor és hol adsz neki értéket? Ezt gondold végig!
Szerk: akkor ennek az oka megvan.
[ Szerkesztve ]
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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)Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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)
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
válasz Superhun #4566 üzenetére
Erre jó megoldás, hogy ha csak tényleg függvényekre, eljárásokra van szükségünk (pl.: különböző segédfüggvények), akkor azokat bedobáljuk egy önálló osztályba public static-ként. Így példányosítás nélkül elérhetjük bárhol a kódunkban.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
-
M_AND_Ms
addikt
válasz Oppenheimer #4604 üzenetére
Az Acrobat az fizetős, nem?
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
-
M_AND_Ms
addikt
É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).
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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.");
}[ Szerkesztve ]
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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)
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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!Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
-
M_AND_Ms
addikt
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.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
Hasonló problémákra gondoltam én is.
Igen. Egyszerű kódot, amolyan baltával is kifaraghatót írni genrerics nélkül kell. Ha cicomázod a generics-szel, akkor farigcsálhatsz órákig. De ha kész, olyan elegáns tud lenni! (csak ne kelljen átfaragni!)
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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ó.Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
válasz Oppenheimer #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ő.Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
"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.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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!
[ Szerkesztve ]
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
válasz juhasz22 #5016 üzenetére
Igen, el van mentve, de az nem visszafejthető. Mondj le róla és nézz utána, miképp lehet új jelszót igényelni!
Ha mégis visszanyerhető lenne a jelszó, akkor meg az egész cuccról mondj le, mert ezek szerint nem biztonságos!
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
-
M_AND_Ms
addikt
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);
[ Szerkesztve ]
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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.Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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!Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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)
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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! ;-)
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
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.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
válasz Aethelstone #5582 üzenetére
91-ben az elektroműszerész suliban elektroncsövekkel ment minden alapkapcsolás...
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
addikt
válasz Aethelstone #5584 üzenetére
Csak a "miért a régi elavult dolgokat tanítják" témához szól
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Újabb Samsungok telepíthetik a Galaxy AI-t
- Futás, futópályák
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- Politika
- Samsung Galaxy Note20 Ultra - a tollnak nincs ellenfele
- btz: Internet fejlesztés országosan!
- Formula-1
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- Kerékpárosok, bringások ide!
- Letartóztatták a bitcoin-Jézust
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen