- HiFi műszaki szemmel - sztereó hangrendszerek
- Házi hangfal építés
- Bluetooth hangszórók
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- SSD kibeszélő
- Gigabyte alaplap topik
- AMD Navi Radeon™ RX 9xxx sorozat
- HP notebook topic
- Fejhallgató erősítő és DAC topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
Új hozzászólás Aktív témák
-
#8031
Aethelstone
addikt
pvt.peter
#8029
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
-
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.
-
#7981
Aethelstone
addikt
pvt.peter
#7977
Aethelstone
addikt
-
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.
-
#7954
Sk8erPeter
nagyúr
pvt.peter
#7951
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. ) -
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.
-
-
#7534
Sk8erPeter
nagyúr
pvt.peter
#7533
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. -
-
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.
-
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.
-
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.
-
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.
-
#3371
Peter Kiss
őstag
pvt.peter
#3370
Peter Kiss
őstag
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; ).)
-
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. -
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
-
MrSealRD
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...
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. 
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- AKCIÓ! HP Elitedesk 800 G1 USDT mini asztali számítógép - i7 4770S 16GB RAM 128GB SSD Intel HD
- BESZÁMÍTÁS! Gigabyte H510M i5 11400F 16GB DDR4 512GB SSD GTX 1070Ti 8GB Rampage SHIVA TT 500W
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- Bomba ár! Lenovo ThinkPad P43s - i7-8G I 8GB I 256GB SSD I Nvidia I 14" FHD I Cam I W10 I Garancia!
- BESZÁMÍTÁS! ASUS ROG Ally Z1 Extreme 512GB SSD játékkonzol garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest