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

• Aethelstone addikt

  #8031

  #8029 pvt.peter

  2015-12-11 11:29: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

  #8029 pvt.peter

  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

  #8030

  #8029 pvt.peter

  2015-12-11 11:27:15

  Ú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

  

  F1rstK1nq

  aktív tag

  #8029 pvt.peter

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

• Aethelstone addikt

  #8028

  #8027 pvt.peter

  2015-12-11 11:09:17

  Ú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

  #8027 pvt.peter

  Az elsőt. Egyértelműen. Egyébként a List<?> nem őse az ArrayList<?> osztálynak. A List egy interfész.

• Aethelstone addikt

  #7981

  #7977 pvt.peter

  2015-12-08 15:45:24

  Ú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

  #7977 pvt.peter

  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.

• floatr veterán

  #7978

  #7977 pvt.peter

  2015-12-08 15:07:16

  Ú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

  #7977 pvt.peter

  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.

• Sk8erPeter nagyúr

  #7954

  #7951 pvt.peter

  2015-12-06 18:11:05

  Ú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

  

  Sk8erPeter

  nagyúr

  #7951 pvt.peter

  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

  #7950

  #7945 pvt.peter

  2015-12-06 16:26:45

  Ú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

  

  PazsitZ

  addikt

  #7945 pvt.peter

  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.

• #39560925 törölt tag

  #7947

  #7945 pvt.peter

  2015-12-06 14:30: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

  

  #39560925

  törölt tag

  #7945 pvt.peter

  Miért Object-eket tárolsz?

• M_AND_Ms veterán

  #7946

  #7945 pvt.peter

  2015-12-06 14:20:52

  Ú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

  #7945 pvt.peter

  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

• Mukorka addikt

  #7546

  #7543 pvt.peter

  2015-06-12 14:10: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

  

  Mukorka

  addikt

  #7543 pvt.peter

  Alapvetően reflectionnel végigmehetsz minden fv-n és aminek nincs paramétere azt meghívhatod aztán megnézed hogy mit adott vissza stb... A node-okon meg visitorral végigmész bár gondolom ez egyértelmű.

• Sk8erPeter nagyúr

  #7534

  #7533 pvt.peter

  2015-06-10 22:56:13

  Ú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

  

  Sk8erPeter

  nagyúr

  #7533 pvt.peter

  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.

• Superhun addikt

  #3556

  #3550 pvt.peter

  2013-03-31 20:51: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

  

  Superhun

  addikt

  #3550 pvt.peter

  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.

• Karma félisten

  #3553

  #3552 pvt.peter

  2013-03-31 12:44:13

  Ú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

  

  Karma

  félisten

  #3552 pvt.peter

  Hát, ezért mondtam a SimpleEntry-t.

  Jó lenne, ha lenne gyárilag Tuple típus, jobbhíján a Pair helyett ez a legegyszerűbb, amihez se kódot nem kell írni, se libet behúzni.

• Karma félisten

  #3551

  #3550 pvt.peter

  2013-03-31 12:09:01

  Ú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

  

  Karma

  félisten

  #3550 pvt.peter

  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

  #3545

  #3543 pvt.peter

  2013-03-31 08:08: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

  

  TBG

  senior tag

  #3543 pvt.peter

  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.

• Superhun addikt

  #3544

  #3543 pvt.peter

  2013-03-30 22:43:49

  Ú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

  

  Superhun

  addikt

  #3543 pvt.peter

  Csinálsz egy osztályt, amiben két mező van: állatnév és egy szám, és felüldefiniálod az equals/hashcode metódusát úgy, hogy az azonos állatnevű és számú objektumok egyezzenek. Ezeket meg pakolhatod egy HashSetbe.

• Karma félisten

  #3535

  #3534 pvt.peter

  2013-03-28 13:30:42

  Ú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

  

  Karma

  félisten

  #3534 pvt.peter

  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.

• Superhun addikt

  #3506

  #3504 pvt.peter

  2013-03-18 23:04:16

  Ú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

  

  Superhun

  addikt

  #3504 pvt.peter

  Szvsz kezdésnek egy szkriptnyelv vagy Delphi/Pascal sokkal egyszerűbb. C-ben nem tudsz programot írni függvény nélkül, míg előbbieknél nincs ilyen probléma.

• fatal` titán

  #3505

  #3504 pvt.peter

  2013-03-18 22:59: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

  

  fatal`

  titán

  #3504 pvt.peter

  Azért a ? : kifejezés nélkül szerintem meg lehet lenni, kicsit többet kell gépelni.

  Nem hiszem, hogy C-vel jó kezdeni, könnyen elveszhet már az elején.

• TBG senior tag

  #3503

  #3502 pvt.peter

  2013-03-18 16:36: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

  

  TBG

  senior tag

  #3502 pvt.peter

  Azon kívül, hogy reagáltál a csávóra? Azt sem mondta, bazdmeg....

• TBG senior tag

  #3474

  #3471 pvt.peter

  2013-03-16 18:01:17

  Ú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

  

  TBG

  senior tag

  #3471 pvt.peter

  Félreértesz. A kódod nagyon jó. Olyan megoldások vannak benne, amiket a kérdező szinte biztosan nem tud értelmezni.

• TBG senior tag

  #3470

  #3469 pvt.peter

  2013-03-16 16:31: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

  

  TBG

  senior tag

  #3469 pvt.peter

  Elnézve az eredeti kódot, a Te megoldásod övön aluli ütésként értelmezhető

• WonderCSabo félisten

  #3460

  #3459 pvt.peter

  2013-03-13 08:24: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

  

  WonderCSabo

  félisten

  #3459 pvt.peter

  Akkor a JDOM sokkal egyszerűbb.

• WonderCSabo félisten

  #3458

  #3456 pvt.peter

  2013-03-12 17:59: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

  

  WonderCSabo

  félisten

  #3456 pvt.peter

  Ha a hatékonyság alatt nem a futási idő gyorsaságát, hanem a használatot érted, akkor pedig a beépített DOM, de sztem még jobb a külső JDOM.

• modder aktív tag

  #3457

  #3456 pvt.peter

  2013-03-12 14:53:18

  Ú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

  

  modder

  aktív tag

  #3456 pvt.peter

  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.

• Scroll Lock tag

  #3429

  #3427 pvt.peter

  2013-02-21 10:38: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

  

  Scroll Lock

  tag

  #3427 pvt.peter

  Azt az osztályt futtatom de hibát ír ki...

• Superhun addikt

  #3424

  #3423 pvt.peter

  2013-02-19 08:55: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

  

  Superhun

  addikt

  #3423 pvt.peter

  A legnagyobb programozási fórum a StackOverflow, én mindenképpen próbálkoznék ott is.

• Superhun addikt

  #3422

  #3420 pvt.peter

  2013-02-17 21:09: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

  

  Superhun

  addikt

  #3420 pvt.peter

  Ez elég nehéz téma, mindenképpen próbálj meg külföldi fórumokon is kérdezni, illetve akár cégekkel is kapcsolatba lépni.

• Taoharcos aktív tag

  #3421

  #3420 pvt.peter

  2013-02-17 18:47:14

  Ú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

  

  Taoharcos

  aktív tag

  #3420 pvt.peter

  Szerintem még meg kéne próbálnod a prog.hu és javaforum.hu oldalakon.

• pvt.peter őstag

  #3420

  #3415 pvt.peter

  2013-02-17 17:46:01

  Ú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

  

  pvt.peter

  őstag

  #3415 pvt.peter

  [erre] senki semmit?

• Peter Kiss őstag

  #3371

  #3370 pvt.peter

  2013-02-02 20:05:06

  Ú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

  

  Peter Kiss

  őstag

  #3370 pvt.peter

  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

  #3369

  #3358 pvt.peter

  2013-02-02 17:41: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

  

  fatal`

  titán

  #3358 pvt.peter

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

• Peter Kiss őstag

  #3367

  #3358 pvt.peter

  2013-02-02 15:03:13

  Ú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

  

  Peter Kiss

  őstag

  #3358 pvt.peter

  Abstract osztályt lehet verziózni (beépíthető plusz metódus default implementációval), míg egy interface-t nem.

• TBG senior tag

  #3366

  #3358 pvt.peter

  2013-02-02 14:59:16

  Ú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

  

  TBG

  senior tag

  #3358 pvt.peter

  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

  #3359

  #3358 pvt.peter

  2013-02-02 13:21: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

  

  MrSealRD

  veterán

  #3358 pvt.peter

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

• Karma félisten

  #3204

  #3202 pvt.peter

  2012-11-29 11:18:39

  Ú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

  

  Karma

  félisten

  #3202 pvt.peter

  A TC Jad Plugin a kedvencem.

• sztanozs veterán

  #3203

  #3202 pvt.peter

  2012-11-29 10:55:15

  Ú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

  

  sztanozs

  veterán

  #3202 pvt.peter

  google: java decompiler

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