- Azonnali mobilos kérdések órája
- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy A54 - türelemjáték
- Yettel topik
- Honor Magic5 Pro - kamerák bűvöletében
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Készülőben a Xiaomi 2021-es csúcsmodelljeinek HyperOS frissítése
- OnePlus 7 - magabiztos folytatás
- Redmi Note 12 Pro - nem tolták túl
- DIGI Mobil
Hirdetés
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
ph A Kereskedelmi Minisztérium egyelőre csak felméri a helyzetet, egyelőre nem látni, hogy tudnak-e bármit is tenni.
Új hozzászólás Aktív témák
-
sztanozs
veterán
válasz pvt.peter #3202 üzenetére
google: java decompiler
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Karma
félisten
-
sutszi
veterán
válasz pvt.peter #3358 üzenetére
Majd ezt még kiegészítik páran...mert amit írok kevés de egy alapvető dolog:
Interfészből bármennyit implementálhat egy osztály.
DE egy osztály csak egyetlen őssel rendelkezhet.
Ezért el kell dönteni a tervezési fázisban, hogy egy adott dolog esetén melyiket kell használni...Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
TBG
senior tag
válasz pvt.peter #3358 üzenetére
Az interfész osztály és az absztrakt osztály közötti különbségek.
E kettő dolog között a különbség "szinte" csak az abstract és az interface kulcsszavak.
Mi még köztük a különbség? Melyiket érdemes használni?Azért ez nem így van. Az interfész gyakorlatilag csak meghatároz megvalósítandó metódusokat.
Ezzel szemben az absztrakt osztályban lehetnek absztrakt metódusok, amiket meg kell valósítani az örökösnek, DE lehetnek benne nem absztrakt metódusok is, amik valami konkrétumot csinálnak.Persze ezt lehet variálni, amikor egy absztrakt osztály megvalósít egy interfészt, de az implementációk absztraktok lesznek.....így azokat az örökösben kell implementálni...és ott már gyakorlatilag nem látszik, hogy az eredetileg az absztrakt osztály absztrakt metódusait valósítom meg vagy az absztrakt osztály által implementált interfész metódusait
És melyiket érdemes? Erre nincs egységes recept. Általánosságban elmondható, hogy ha többszörös öröklődést akarsz megvalósítani(ami Javában alapból nincs), akkor interfész, de ha tuti, hogy csak egy őst akarsz, de kellenek default metódusok is, akkor absztrakt. Perszem azt is lehet, hogy
Interface-->default class implements interface-->örökös
vagy
absztrakt class-->örökös
vagy
Interface->absztrakt class absztrakt metódusok-->örökös
szóval...a lehetőségek végtelen tárháza
[ Szerkesztve ]
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
-
-
fatal`
titán
válasz pvt.peter #3358 üzenetére
"Mi még köztük a különbség? Melyiket érdemes használni?"
Származtatáskor van különbség. Ha nincs szükséged semmilyen függvény implementációjára (értsd, olyan abstract osztályod lenne, amiben csak abstract függvények vannak), akkor érdemes interfacet használni, mert interfaceből egy osztály bármennyit implementálhat, viszont származtatni csak egy osztályból lehet. -
válasz pvt.peter #3370 üzenetére
Van egy abstract osztályod, benne dolgokkal. Két év múlva kiderül, hogy jó lenne, ha lenne benne plusz egy metódus. Simán lehet módosítani az osztályt anélkül, hogy a régi kódokat elrontanád vele.
Interface esetén ezt nem lehet kivitelezni: ha bekerül az interface-be egy plusz elem, akkor azt a régi kódokban is implementálni kell. (Abstract osztály esetén lehet pl. az adott új metódusnak üres blokkja vagy egy default implementációja (pl. return null; ).)
[ Szerkesztve ]
-
modder
aktív tag
válasz pvt.peter #3456 üzenetére
Nem vagyok egy nagy XML vadállat, csak mostanában kellett. Attól függ, hogy akarod használni.
ha entitást akarsz generálni az xml-ből oda-vissza, akkor JAXB (Metro, de inkább Eclipse Moxy implementációt használd, mert kevésbé bugos).
Ezt nagyon egyszerű használni.Ha több kontroll kell, akkor pl StAX API.
Én most a kettőt együtt használtam, mert alá kellett írni az eredeti xml üzenetet, ami sokféle típusú lehet. szóval fogtam, jaxb-vel legenerelátam az üzenet xml-t, szintén jaxb-vel legeneráltam a signature objektumból az xml-t, majd StAX-szal a kettőből összeheggesztettem egy nagyon egyszerű xml-t, ami a kettőt tartalmazza.
-
Karma
félisten
válasz pvt.peter #3534 üzenetére
Ez egy fontos tervezési elv kicsiben. Amikor a változót később használod, nem függ így a kódod attól, hogy a változó konkrétan egy HashMapet takar, csak hogy megfelel a Map interfésznek - más szóval kulcs-érték párokat tudsz tárolni benne.
Így a későbbi kód módosítása nélkül kicserélheted például TreeMapre (ami hashtábla helyett piros-fekete fában tárolja az értékeket), ha a helyzet úgy kívánja. Vagy akár egy tömbre, amiben lineáris kereséssel túrod ki a megfelelő értéket. A lényeg az, hogy milyen szolgáltatást nyújt, nem az, hogy konkrétan hogyan oldja meg.
Azért mondom, hogy kicsiben, mert egy függvényen belül ennek nincs nagy jelentősége, maximum szoktatod magad csak az interfészek deklarálásához. Nagyobb programban viszont, ahol komponensek kapcsolódnak egymáshoz, ez már kritikussá válik. És jönnek olyan finomságok, mint Dependency Inversion.
[ Szerkesztve ]
“All nothings are not equal.”
-
TBG
senior tag
válasz pvt.peter #3543 üzenetére
Superhun megoldása teljesen jó.
Viszont ha már saját osztályt használsz felüldefiniált metódusokkal, akkor szerintem elég az equals felüldefiniálni úgy, hogy a String és az int egyezőség esetén adjon vissza TRUE-t és akkor egy "sima" ArrayList-be is teheted. Persze attól is függ, hogy mennyi elemed lesz, mert nagyon sok elem esetén az ArrayList nem túl gazdaságos. Nem mondom, hogy Superhun vagy az én megoldásom a jobb, az enyém egy alternatív, de valamivel egyszerűbb megoldás, mert csak 1 metódus felüldefiniálását kell megcsinálni, de mint írtam, sok elemnél nem feltétlenül gazdaságos.
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
-
Karma
félisten
válasz pvt.peter #3550 üzenetére
Ilyen megoldásoknak szerintem nincs helye egy Java topikban. De igazából semmilyen szakmaiban se. Stringben eltárolni a számot? Nooormális?
Ha nem akarsz saját adatosztályt írni, akkor legalább a AbstractMap.SimpleEntryt használd az adatpár tárolására. Ezt meg belerakhatod a HashSetbe.
[ Szerkesztve ]
“All nothings are not equal.”
-
addikt
válasz pvt.peter #3550 üzenetére
Pedig pont, hogy túlbonyolítod a string tömbökkel a dolgot. Azt hogy tervezted leellenőrizni, hogy az adott pár benne van-e már az ArrayList-ben? Contains-szal? Lassabb működést kapsz, a castolás gányolásról nem is beszélve.
Edit: az utóbbi megoldás sokkal szebb.
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
válasz pvt.peter #7533 üzenetére
Konkrétabban mit takar a "felokosítás"?
(#7528) sutszi:
Jaja, két számjegy viszont simán elfér a tálcaikonon (ld. HWiNFO64 tálcára kirakott kijelzői). Három már elég necces (a töltöttség kijelzésénél mondjuk csak egy esetben van erre szükség, 100%-nál )... Igazából két számjegy esetén állapotjelzésre a tálcaikon a legjobb megoldás, háromnál para. De próbát megér, max. kisebbek lesznek a betűk, vagy 100% esetén egy teljes töltöttséget jelző egyéb ikont mutatsz, nem számot.[ Szerkesztve ]
Sk8erPeter
-
Mukorka
addikt
-
M_AND_Ms
addikt
válasz pvt.peter #7945 üzenetére
Az első, mivel a kész listával még van dolgod (hogy belerakd, amit akarsz), ezért jó, ha az megvan. A második esetben rögtön berakod a listát a Map-be, így azt egyből vissza is kell keresned, ami mégiscsak idő és energia
[ Szerkesztve ]
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
veterán
-
PazsitZ
addikt
válasz pvt.peter #7945 üzenetére
Az első esetnél egy temp referencia van, a második esetnél van a Map get és egy cast művelet.
Nem hiszem, hogy ilyeneket szintű dolgokat kellene túlpörögni optimalizáció szempontból.Ha nagyon rövidíteni akarsz, ezek is használhatóak:
objects.put(actualKeyObject, new ArrayList<Object>() {{ add(actualValueObject); }});
objects.put(actualKeyObject, Arrays.asList(actualValueObject));Egyébként inkább abba az irányba gondolkodnék, hogy ha több elemet pakolunk a listába, akkor azt külön metódusba kiszervezni és az első példa szerint hozzáadni érdemesebb/átláthatóbb szerintem.
Egy elemű lista esetén viszont számomra inkább az inline megoldások a szimpatikusabbak.
[ Szerkesztve ]
- http://pazsitz.hu -
-
Sk8erPeter
nagyúr
válasz pvt.peter #7951 üzenetére
Szerintem egyáltalán nem csúnya, hogy külön sorba rakod, hogy mit művelsz azzal a listával, amit majd be szeretnél rakni a HashMapbe. Sőt, gyorsan olvasható, egyértelmű, tiszta, és elkerülsz vele egy tök felesleges plusz metódushívást. A második is jól olvasható, de tény, hogy pazarlóbb. Így egy elemnél aztán tényleg totál mindegy teljesítmény szempontjából, meg láthatóság szempontjából is, de én meg attól kaparom az arcom, amikor olyan kódot kell olvasnom, amikor láthatóan a fejlesztő célja az volt, hogy vagányan mindent minél rövidebbre tömörítsen. Az sem számít, hogy hányszor ismétel azonos metódushívásokat, hány plusz műveletet igényel, de milyen jól mutat, hogy legalább tömör. Hát nem, nem lesz feltétlenül gyorsabban olvasható a kód (persze nyilván bőven vannak kivételek, de ne fossuk már le ennyire a teljesítményt). Tényleg valakinek attól lesz olvashatatlan a kód, mert külön sorban ki van fejtve, hogy mi történik? Az már régen rossz. Magasszintű nyelveknél egyébként nagyon divat(tá vált?) az is, hogy a metódushívásokat egymás után is ismételgetjük, mondván, "nem kell túlpörögni optimalizáció szempontjából", mint a kolléga mondta, ez itt abszolút igaz, de általában ezzel nagyon nem értek egyet. Egyrészt ha ennyire leszarjuk, hányszor történik meg egy-egy metódushívás, akkor az már zsigeri szintű igénytelenséghez vezethet hosszabb távon a teljesítmény rovására, meg azért szépen lehet halmozgatni az ilyen tök felesleges overheadeket, na de minek. (Persze ebben az is szerepet játszik, hogy ebből a szempontból mai napig bennem van a C, C++ tanulásának korszaka, amikor az ilyesmi nem volt menő.)
Pl. ilyesmi:
whatever.doStuff().veryCool().blahblah();
whatever.doStuff().veryCool().wow().great();
whatever.doStuff().veryCool().notCool();
Na itt pl. a whatever.doStuff().veryCool() eredményét el lehetett volna tárolni egy változóba. De nem, ez így tök menő. Ja várjunk csak, mégsem.Szerk.:
Persze simán lehet, hogy az ilyeneket a fordító úgyis optimalizálja. Mindegy, bennem az van, hogy abból baj nincs, ha egyértelműen láthatóvá teszem, mi történik, nekem a pár sorral bővebben hablatyolós kód nem lesz olvashatatlanabb, az agyontömörített kód viszont annál inkább. (Meg a debuggolást is nehezebbé teheti. )[ Szerkesztve ]
Sk8erPeter
-
floatr
veterán
válasz pvt.peter #7977 üzenetére
Létezik az, hogy a VM memóriát pucol, betölt, lefordít, becache-el dolgokat, de az elméletileg első futtatáskor megtörténik. Ez a jelenség más infrastruktúrán is jelentkezik.
Azt viszont a teljesítményteszteknél érdemes megjegyezni, hogy mindig lesznek kiugróan rossz, vagy jó eredmények, ami nem igazán tükrözi a normál körülményeket. Használnak emiatt sokféle statisztikai mutatót, de nekem eddig a legjobban a medián jött be, az egyszerű átlagolás könnyen elvisz a málnásba.
Ja és természetesen lehetőleg kellően sok futtatás kell ahhoz, hogy valós képet kapjál. Ha az elsőt mondjuk eldobod, után mondjuk 10 mérés már sok esetben elég tud lenni.
[ Szerkesztve ]
-
Aethelstone
addikt
válasz pvt.peter #7977 üzenetére
Meg azt sem árt tudni, hogy ezek a komponensek mit csinálnak. Adatbázis kapcsolat pl. elsőre kissé le tudja fogni a teljesítményt, de ha mondjuk pool van kötve a végére, akkor a második és sokadik futás értelemszerűen már sokkal gyorsabb...és sorolhatnám.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
F1rstK1nq
aktív tag
válasz pvt.peter #8029 üzenetére
Így megmarad az az előnyöd, hogy csak a Lista implementációját változtatod meg példányosításkor, a kód többi része változatlan marad. (Például ha úgy döntesz, ArrayList helyett LinkedList-et használsz később)
Clean Code szerint egyébként érdemes szinte minden esetben a referencia értéknek a még legmagasabb értelmes interfészt megadni.
Adrenaline is natures way of telling you 'don't fuck up.'
-
Aethelstone
addikt
válasz pvt.peter #8029 üzenetére
Többalakúság.
Problémák:
Ha szeretnéd kicserélni mondjuk egy LinkedList-re az ArrayListet, akkor nem tudod megtenni, mivel az eredeti változód típusa explicit ArrayList. Ha biztosan tudod, hogy az a változó az idők végezetéig ArrayList marad (ezt nem tudhatod), akkor maradhatna.
Másrészt meg nem szép. Kódolási konvenció a Collectionok esetében, hogy nem implementációt, hanem interfészt adunk meg ilyen esetben.
Érdemes "megszeretni" az interface típusú deklarációt, mivel egy csomó framework is így műx, pl. a Spring-es dependency injection esetében is interészekeket injektálsz, nem implementációkat.
Teljesítménygondok nem hiszem, hogy lennének.
szerk: Kolléga megelőzött
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Azonnali mobilos kérdések órája
- Vezetékes FEJhallgatók
- Politika
- Projektor topic
- Autós topik látogatók beszélgetős, offolós topikja
- Milyen légkondit a lakásba?
- Honor Magic6 Pro - kör közepén számok
- Mr Dini: Mindent a StreamSharkról!
- Samsung Galaxy A54 - türelemjáték
- Villanyszerelés
- További aktív témák...