- One mobilszolgáltatások
- Samsung Galaxy Watch8 és Watch8 Classic – lelkes hiperaktivitás
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Yettel topik
- Poco F8 Ultra – forrónaci
- Samsung Galaxy S25 - végre van kicsi!
- Fotók, videók mobillal
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 17 - még mindig tart
Új hozzászólás Aktív témák
-
Aethelstone
addikt
jogos észrevétel, elnézést a megfogalmazásért
és mi a magyarázat erre?
kevesebb overhead?
egyszerűbb, kevesebb bájtkód jön létre?
vagy esetleg jobban tud optimalizálni a VM?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
-
Aethelstone
addikt
Sziasztok,
Akadt még egy kérdésem ami lehet, hogy hülyeség, de lehet hogy nem.
Ha van egy függvényünk, akkor az alábbiak közül melyik változatát érdemesebb használni?
Itt most a hangsúly azon van, hogy ős típusú vagy már kapásból leszármaztatott típusú legyen az a bizonyos változó.
Ez most nem összekeverendő a "dependency injection" -el.
A temp lokális változóhoz nem lesz később hozzárendelve semmilyen más érték.public void function1(){
List<Object> temp = new ArrayList<Object>();
}public void function1(){
ArrayList<Object> temp = new ArrayList<Object>();
} -
Aethelstone
addikt
Sziasztok!
Lenne egy érdekes kérdésem.
Adott egy rendszer amelyben az egyik igen csak teljesítményigényes végrehajtó részt, kísérleti jelleggel több komponens is megvalósítja.
A lényeg, hogy ezeknek a komponenseknek a teljesítményét szeretném mérni.
Nem bonyolítom túl az egészet, egyszerűen csak futási időt fogok mérni a System.nano() hívással.long start = System.nanoTime();
...
long end = System.nanoTime() - start;Mennyire valós dolog az, hogy a Java lassan "melegszik" be.
Tehát ha én egy adott függvény teljesítményét akarom lemérni, akkor az első 5-6 futás eredményét tényleg érdemes-e eldobni?A válaszokat előre is köszönöm,
Peti -
Sziasztok!
Lenne egy érdekes kérdésem.
Adott egy rendszer amelyben az egyik igen csak teljesítményigényes végrehajtó részt, kísérleti jelleggel több komponens is megvalósítja.
A lényeg, hogy ezeknek a komponenseknek a teljesítményét szeretném mérni.
Nem bonyolítom túl az egészet, egyszerűen csak futási időt fogok mérni a System.nano() hívással.long start = System.nanoTime();
...
long end = System.nanoTime() - start;Mennyire valós dolog az, hogy a Java lassan "melegszik" be.
Tehát ha én egy adott függvény teljesítményét akarom lemérni, akkor az első 5-6 futás eredményét tényleg érdemes-e eldobni?A válaszokat előre is köszönöm,
Peti -
Sk8erPeter
nagyúr
Tlképpen csak egy O(1) -el van több műveletem a 2. -ban, nem?
Ez pedig a hash kód alapján való elem lekérés a getKey segítségével.
Bár lehet hogy ugrálni kell majd a hash táblában mert a hasítófüggvény nem elég precíz ahhoz, hogy olyan kódot tudjon gyártani amihez biztos, hogy nem tartozik még semmi se.
(fix me, de asszem vmi ilyesmin alapszik a map ... )Ettől függetlenül igen, az elsőt célszerű használni.
A kérdésemet csak azért raktam fel, mert mindig csak egy elemet rakok bele abba a listába és kicsit csúnya volt, hogy mindig létre kell hoznom egy temp listát ehhez.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. ) -
Sziasztok!
Szerintetek melyik konstrukciót célszerűbb használni?
Pl. olvashatóság, performancia szempontjából.Map<Object, List<Object>> objects = new HashMap<Object, List<Object>>();
List<Object> temp = new ArrayList<Object>();
temp.add(actualValueObject);
objects.put(actualKeyObject, temp);vagy:
Map<Object, List<Object>> objects = new HashMap<Object, List<Object>>();
objects.put(actualKeyObject, new ArrayList<Object>());
objects.getKey(actualKeyObject).add(actualValueObject);Előre is köszi,
Peti -
Sziasztok!
Szerintetek melyik konstrukciót célszerűbb használni?
Pl. olvashatóság, performancia szempontjából.Map<Object, List<Object>> objects = new HashMap<Object, List<Object>>();
List<Object> temp = new ArrayList<Object>();
temp.add(actualValueObject);
objects.put(actualKeyObject, temp);vagy:
Map<Object, List<Object>> objects = new HashMap<Object, List<Object>>();
objects.put(actualKeyObject, new ArrayList<Object>());
objects.getKey(actualKeyObject).add(actualValueObject);Előre is köszi,
Peti -
Sziasztok!
Szerintetek melyik konstrukciót célszerűbb használni?
Pl. olvashatóság, performancia szempontjából.Map<Object, List<Object>> objects = new HashMap<Object, List<Object>>();
List<Object> temp = new ArrayList<Object>();
temp.add(actualValueObject);
objects.put(actualKeyObject, temp);vagy:
Map<Object, List<Object>> objects = new HashMap<Object, List<Object>>();
objects.put(actualKeyObject, new ArrayList<Object>());
objects.getKey(actualKeyObject).add(actualValueObject);Előre is köszi,
Peti -
Szia!
Hát eddig C#-ban dolgoztam, most viszont belekell ugranom Javaba is.
Tehát adott egy forráskód elemző, amely Javaban lett írva és egy másik nyelvből húz fel forráskód alapján egy AST -t.
Adott node -nak rendkívül sok függvényét tudjuk meghívni.
Nincs kedvem ezeket kézzel leírogatni és változót létrehozni és arra gondoltam, hogy van-e esetleg vmi automatizált módszer arra, hogy ezeknek a függvényhívásoknak az eredményét megtudjam vizsgálni?
Természetesen csak a paraméter nélküli fgvekről van most szó.
Elég sok öröklődés van benne meg változó meg minden eltorzult dolog -
Sk8erPeter
nagyúr
Sziasztok!
Azt szeretném megkérdezni, hogy Eclipsehez tud vki egy olyan kiegészítőt ami a beépített debuggert, ezen belül is a Variables nézetért felelős részt feltudja esetleg egy kicsi "okosítani"?
Előre is köszi,
PetiKonkré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. -
uh, nem akartam osztályokkal megvalósítani ezt, abszolút kollekciókban gondolkozok, ugyanis kb. olyan lenne, mint ágyúval verébre lőni
ezt az adatpakolgatást is static { } -ben végzem, bár már ez megvolt írva
tehát annyi az egész, hogy van kb. 20-30 adatpárom az előbbi szabályokkal definiálva
majd van egy fgvem, ami kap 2 paramétert, egy Stringet és egy intet
és lecsekkolja, hogy ebben az adott akármiben benne van-eennyi lenne a feladat, erre meg nem akartam osztályt írni, hisz nem nagy dolog
kollekciókkal szeretném megoldani,
pl. ez is elvégezné a feladatot: ArrayListbe egy String tömb és kész, a String tömb meg ugye kételemű lenne ("kutya" - "1")
majd legfeljebb castolgatom az int értéketPedig 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.
-
-
uh, nem akartam osztályokkal megvalósítani ezt, abszolút kollekciókban gondolkozok, ugyanis kb. olyan lenne, mint ágyúval verébre lőni
ezt az adatpakolgatást is static { } -ben végzem, bár már ez megvolt írva
tehát annyi az egész, hogy van kb. 20-30 adatpárom az előbbi szabályokkal definiálva
majd van egy fgvem, ami kap 2 paramétert, egy Stringet és egy intet
és lecsekkolja, hogy ebben az adott akármiben benne van-eennyi lenne a feladat, erre meg nem akartam osztályt írni, hisz nem nagy dolog
kollekciókkal szeretném megoldani,
pl. ez is elvégezné a feladatot: ArrayListbe egy String tömb és kész, a String tömb meg ugye kételemű lenne ("kutya" - "1")
majd legfeljebb castolgatom az int értéket -
Sziasztok!
Egy érdekes, de nem nehéz problémába ütköztem, igazából van is rá elképzelésem, de hátha kapok jobb ötletet tőletek.
Tehát adatokat kellene tárolnom vmiben (természetesen vmi kollekcióra gondoltam).Két részből áll:
egy String és egy intA string értéke és az int értéke is ismétlődhet, tehát pl.: ezek a párosok fordulhatnak elő:
"kutya" - 2
"kutya" - 1
"macska" - 1Látható, hogy egy vagy több String is megegyezhet egymással és egy vagy több int is megegyezhet egymással, viszont nem lehetnek olyan párosok ahol a String és az int is megegyezne.
Tehát tlképpen mindegyik páros egyértelműen azonosítható a String értékkel és az int értékkel.
Olyan mintha egyszerre használnám őket kulcsnak.A kérdésem: melyik kollekciót lenne érdemes erre a feladatra használni?
Időigény, elérés nem számít, de azért ne legyen nagyon undormány és gány.
HashMap egymagában nem jöhet szóba a fentiek miatt.
Össze kellene ágyazni min két kollekciót, csak nem tudom melyik lenne a legmegfelelőbb erre a célra, ami még talán elegáns is lenne.Ha esetleg vki tud vmi elfogadható és vállalható megoldást erre, akkor ne tartsa magában
-
Sziasztok!
Egy érdekes, de nem nehéz problémába ütköztem, igazából van is rá elképzelésem, de hátha kapok jobb ötletet tőletek.
Tehát adatokat kellene tárolnom vmiben (természetesen vmi kollekcióra gondoltam).Két részből áll:
egy String és egy intA string értéke és az int értéke is ismétlődhet, tehát pl.: ezek a párosok fordulhatnak elő:
"kutya" - 2
"kutya" - 1
"macska" - 1Látható, hogy egy vagy több String is megegyezhet egymással és egy vagy több int is megegyezhet egymással, viszont nem lehetnek olyan párosok ahol a String és az int is megegyezne.
Tehát tlképpen mindegyik páros egyértelműen azonosítható a String értékkel és az int értékkel.
Olyan mintha egyszerre használnám őket kulcsnak.A kérdésem: melyik kollekciót lenne érdemes erre a feladatra használni?
Időigény, elérés nem számít, de azért ne legyen nagyon undormány és gány.
HashMap egymagában nem jöhet szóba a fentiek miatt.
Össze kellene ágyazni min két kollekciót, csak nem tudom melyik lenne a legmegfelelőbb erre a célra, ami még talán elegáns is lenne.Ha esetleg vki tud vmi elfogadható és vállalható megoldást erre, akkor ne tartsa magában
-
Sziasztok!
Biztos nagyon amatőr kérdés lesz, de ha pl. van egy ilyen:
Map<String, Person> people = new HashMap<String, Person>();
akkor a people változót miért nem így deklaráljuk:
HashMap<String, Person> people = new HashMap<String, Person>();Ha már így is úgy is HashMap<String, Person>(); lesz belőle?
Egyáltalán miért jó ez a sima Map -féle deklarálás?
Előre is köszi a kiigazítást.
-
nekem ez nem tartott sokáig, főleg úgy, hogy eclipse megvolt nyitva
véleményem szerint ha vki programozással szeretne kezdeni, akkor ne ugorjon neki azonnal az OOP-nek
érdemes sima C -vel kezdeni, egyrészt azért, hogy pl. tisztában legyen a ? : kifejezéssel
persze nekem is van még sok mindent tanulnom -
nekem ez nem tartott sokáig, főleg úgy, hogy eclipse megvolt nyitva
véleményem szerint ha vki programozással szeretne kezdeni, akkor ne ugorjon neki azonnal az OOP-nek
érdemes sima C -vel kezdeni, egyrészt azért, hogy pl. tisztában legyen a ? : kifejezéssel
persze nekem is van még sok mindent tanulnom -
lehet nem egy profi kód, mondjuk a konstruktorból kiszedhettem volna a this.price * részeket
de ezt leszámítva miért lenne övön aluli ütés?
Azt csinálja ami a feladat.Félreértesz. A kódod nagyon jó. Olyan megoldások vannak benne, amiket a kérdező szinte biztosan nem tud értelmezni.
-
elég sokféleképpen meglehet oldani
Obj.java
package bikeshop;
public class Obj {
private final int ordertime;
private final boolean ordertype;
private int price;
public Obj(int ordertime, boolean ordertype) {
this.ordertime = ordertime;
this.ordertype = ordertype;
this.price = (this.ordertime >= 1 && this.ordertime <= 5) ? 10 : 30;
this.price += this.ordertype ? 10 : 5;
}
public int getPrice() {
return this.price;
}
}Main.java
package bikeshop;
public class Main {
public static void main(String[] args) {
Obj obj = new Obj(5, false);
System.out.println("Price: " + obj.getPrice());
}
}Elnézve az eredeti kódot, a Te megoldásod övön aluli ütésként értelmezhető
-
WonderCSabo
félisten
-
WonderCSabo
félisten
-
Scroll Lock
tag
-
@Taoharcos: elnézek arra is
@Superhun: próbálkoztam már külföldi fórumon, eddig eredménytelenül
Cégekkel való kapcsolatfelvételben én is gondolkoztam, a következő lépések közé teszemA legnagyobb programozási fórum a StackOverflow, én mindenképpen próbálkoznék ott is.
-
Sziasztok!
Ezt posztot az Android programozás -hoz is beírtam, de mivel Java -hoz is kapcsolódik, ezért ide is beírom. Tehát:
szeretnék kérni egy kis segítséget Tőletek, ugyanis Android platformmal kapcsolatban fogok szakdolgozatot írni, illetve részt venni egy projektben.
A dolgozat címe: Android alkalmazások minőségbiztosítása - egy minősítő modell kidolgozása és eredményeinek validálása.
Elég tág téma így első hallásra, ezért is megpróbálom behatárolni nagyjából.
Először is ezen a projekten 3 fő fog dolgozni, beleértve engem is.
Ezek a körök kerülnek feldolgozásra, illetve ezeket kellene feldolgozni a projekt során:1) Android GUI XML-ek elemzése, új metrikák definiálása
magának az Android alkalmazás felhasználói felületének elemzése meglévő illetve új metrikák bevezetésével
2) Andorid Java kód elemzése, új metrikák definiálása
Android specifikus kód elemzése meglévő illetve új metrikák bevezetésével
3) Minőségi modell adaptálása Androidra, minőségi eredmények és felhasználói vélemények statisztikai összefüggéseinek keresése
az előző két pontban definiált részek használata és eredményeinek felhasználása a felhasználói visszajelzések összehasonlításábanLátható, hogy nem új keletű dolgok kerülnek feldolgozásra, elemzésre, hanem már létező (különálló) rendszert kell átdolgozni magára az Android platformra.
Annyiban új a dolog, hogy még nem igazán vannak speciel Android alkalmazások minőségbiztosításával foglalkozó területek, projektek, ebből adódóan ez a projekt leginkább kutatás/fejlesztés témába sorolható.
Ehhez elsősorban irodalmat kell kutatni.
Találtam is ezzel foglalkozó cikket, SAMOA (ha valaki tud ehhez hasonló cikket, publikációt akkor azt is szívesen veszem).Illetve lenne még kérdésem, ami leginkább azokhoz szól, akik foglalkoztak/foglalkoznak szoftverek minőségbiztosításával:
Érdekelne engem minden ezzel kapcsolatos forrás, tehát amit érdemes feldolgozni, ami mentén érdemes elindulni. (link, cikk, publikáció, bármi)
Ez vonatkozik mind az XML, illetve az Android specifikus Java kódra.
Pl. Android specifikus szabályok gyűjteményeAjánlásokat illetve a segítséget előre is köszönöm
[erre] senki semmit?
-
Peter Kiss
őstag
-
Sziasztok!
Egy kérdés merült fel bennem interfészekkel kapcsolatban.
Tehát interfész definíciója: (teljesség hiányával)
"Minden operáció impliciten absztrakt"
->tehát csak az adott fgv. feje van az interfészben, tehát csak definiálva vanAz implicit szót nem véletlen emeltem ki az előbb.
Azt is tudjuk, hogy az interfész az egy speciális absztrakt osztály.
Absztrakt osztály definíciója, többek közt:
Egy osztály absztrakt osztály, ha legalább egy absztrakt metódust tartalmaz.Egy absztrakt osztály tartalmazhat olyan absztrakt függvényt, amelynek van implementációja abban az adott absztrakt osztályban.
És itt jönne a kérdésem:
Impliciten absztraktnak nevezzük az előbb említett interfészben levő operációt, míg explicitnek nevezzük az utóbb említett absztrakt osztályban levő absztrakt függvényt amelynek van implementációja?A kérdésemmel arra szeretnék rávilágítani, hogy helyesen mondtam-e az explicit és az implicit közötti különbséget.
Illetve lenne még vmi.
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? -
Peter Kiss
őstag
Sziasztok!
Egy kérdés merült fel bennem interfészekkel kapcsolatban.
Tehát interfész definíciója: (teljesség hiányával)
"Minden operáció impliciten absztrakt"
->tehát csak az adott fgv. feje van az interfészben, tehát csak definiálva vanAz implicit szót nem véletlen emeltem ki az előbb.
Azt is tudjuk, hogy az interfész az egy speciális absztrakt osztály.
Absztrakt osztály definíciója, többek közt:
Egy osztály absztrakt osztály, ha legalább egy absztrakt metódust tartalmaz.Egy absztrakt osztály tartalmazhat olyan absztrakt függvényt, amelynek van implementációja abban az adott absztrakt osztályban.
És itt jönne a kérdésem:
Impliciten absztraktnak nevezzük az előbb említett interfészben levő operációt, míg explicitnek nevezzük az utóbb említett absztrakt osztályban levő absztrakt függvényt amelynek van implementációja?A kérdésemmel arra szeretnék rávilágítani, hogy helyesen mondtam-e az explicit és az implicit közötti különbséget.
Illetve lenne még vmi.
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? -
Sziasztok!
Egy kérdés merült fel bennem interfészekkel kapcsolatban.
Tehát interfész definíciója: (teljesség hiányával)
"Minden operáció impliciten absztrakt"
->tehát csak az adott fgv. feje van az interfészben, tehát csak definiálva vanAz implicit szót nem véletlen emeltem ki az előbb.
Azt is tudjuk, hogy az interfész az egy speciális absztrakt osztály.
Absztrakt osztály definíciója, többek közt:
Egy osztály absztrakt osztály, ha legalább egy absztrakt metódust tartalmaz.Egy absztrakt osztály tartalmazhat olyan absztrakt függvényt, amelynek van implementációja abban az adott absztrakt osztályban.
És itt jönne a kérdésem:
Impliciten absztraktnak nevezzük az előbb említett interfészben levő operációt, míg explicitnek nevezzük az utóbb említett absztrakt osztályban levő absztrakt függvényt amelynek van implementációja?A kérdésemmel arra szeretnék rávilágítani, hogy helyesen mondtam-e az explicit és az implicit közötti különbséget.
Illetve lenne még vmi.
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 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
-
Sziasztok!
Egy kérdés merült fel bennem interfészekkel kapcsolatban.
Tehát interfész definíciója: (teljesség hiányával)
"Minden operáció impliciten absztrakt"
->tehát csak az adott fgv. feje van az interfészben, tehát csak definiálva vanAz implicit szót nem véletlen emeltem ki az előbb.
Azt is tudjuk, hogy az interfész az egy speciális absztrakt osztály.
Absztrakt osztály definíciója, többek közt:
Egy osztály absztrakt osztály, ha legalább egy absztrakt metódust tartalmaz.Egy absztrakt osztály tartalmazhat olyan absztrakt függvényt, amelynek van implementációja abban az adott absztrakt osztályban.
És itt jönne a kérdésem:
Impliciten absztraktnak nevezzük az előbb említett interfészben levő operációt, míg explicitnek nevezzük az utóbb említett absztrakt osztályban levő absztrakt függvényt amelynek van implementációja?A kérdésemmel arra szeretnék rávilágítani, hogy helyesen mondtam-e az explicit és az implicit közötti különbséget.
Illetve lenne még vmi.
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?
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- One mobilszolgáltatások
- Google Chromecast topic
- Crypto Trade
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy Watch8 és Watch8 Classic – lelkes hiperaktivitás
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Kerékpárosok, bringások ide!
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- Fujitsu LIFEBOOK E459 I3-8130U 8 GB 256 GB NVMe 15,6" FullHD laptop
- HP ProBook 450 G8 I3-1115g4 8 GB 256 GB NVMe 15,6" FullHD IPS laptop
- Lenovo Thinkpad T14 G2 Ryzen 3 5450u/16GB/256 GB SSD/14"FHD gyári gar
- HP Elite x2 G4 I5-8265U/8 GB RAM/256 SSD/3k IPS TOUCH 2in1 laptop és tablet
- Új MSI 16 Sword WUXGA 144Hz i7-14650HX 5.2Ghz 16mag 16GB 1TB SSD Nvidia RTX 4070 8GB Win11 Garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest