Fórumok
Van egy tömb JAVA 8-ban
List<Elemek> list;
public class Elemek{
private final int id;
public Elemek(int id) {
this.id = id;
}
public int getId() {
return this.id;
}
}
public class A extends Elemek
{
private int valtozo_A;
public A(final int id, final int valtozo_A) {
super(id);
this.valtozo_A = valtozo_A;
}
public int getValtozo_A() {
return this.valtozo_A;
}
}
public class B extends A;
{
private int valtozo_B;
public B(final int id, final int valtozo_A, final int valtozo_B) {
super(id);
this.valtozo_A = valtozo_A;
this.valtozo_B = valtozo_B;
}
public int getValtozo_B() {
return this.valtozo_B;
}
}
List<Elemek> list = new ArrayList();
B b = new B(1, 2, 3);
list.add(b);
((B) list.get(0)).getValtozo_B(); // 3
Ha belerakom a tömbbe az A-t vagy a B-t, és kiolvasom,
akkor levágja az valtozo_A-t és a valtozo_B-t és az mindig null-t ad vissza:
(B) list.get(0);
Hogy lehet ezt megoldani?
Tényleg valamit interface-nek kell definiálni, de miért?
Nem tudom törölni a "final"-okat a konstruktorokból, mert az IntelliJ fejlesztőkörnyezet visszarakja őket.
Megoldódott végül. Nem ott volt a baj, hanem hiányzott valami teljesen más, avagy
jóval előtte egy kitöltetlen mező blokkolta, hogy eljusson oda, avagy nem levágta, hanem más volt a baj.
Végül nem kellett az interface.
Hozzászólások
Esetleg valami kevésbé (enyhén szólva) hibás kóddal és azzal, ha megmutatod, hogy mit hogy teszel abba a list-be, valamint elárulod, hogy hogy jön ide a
list.elementAt(0);
(nem inkábblist.get(0);
?), akkor könnyebb lenne segíteni :)Csatlakozom az előttem szólóhoz, inkább kezdjük ott, hogy mit is szeretnél elérni, és megpróbálunk segíteni. Ez így olyan lyukas minden szinten, mint egy ementáli sajt :D
1. ez nem tömb hanem lista
2. "vissza kell castolnod" az extended class-ra ha el akarod érni a base class (Elemek)-n felüli részeit.
Gábriel Ákos
Szerintem olvass el egy Java kezdőknek könyvet. A List az nem tömb, a polimorfizmus pedig nem töltelékszó.
Valószínűleg épp azt teszi.
És ha igen, akkor egy kicsit több konstruktivizmus nem árthat meg; senki se úgy kezdte az ipart, hogy mindent egyből vágott, vagy egyáltalán sikerült értelmes kérdést feltennie.
Vicces amúgy, de (mi) annyira nem használunk tömböt manapság Java-ban, hogy ahányszor mégis szükségem lenne rá, ki kell guglizom, hogy kell Java-ban tömböt inicializálni, mert egyszerűen nem emlékszem :)
private változót nem fogsz tudni elérni kívülről. Vagy deklaráld publicnak, vagy, ami Java best practice, adj neki egy getter függvényt:
Illetve a castolásnál lehet kell neked még egy zárójel:
A fentiek fejből, szóval a tévedés jogát fenntartom.
Szerk:
.elementAt() az vektorhoz való, de te listát definiálsz, ott meg .get() van (vektort ne is használj manapság SO szerint: https://stackoverflow.com/a/18248807).
--------
Szerk2:
az NPE-t valószínüleg azért kapod, mert nem inicializáltad a listát:
Próbáld így.
Szerk3: elnéztem a B konstruktorát, az A értékadás a super-be megy. Javítva.
Oké, megváltoztattam, de szerintem nem itt lesz a baj.
Igen a getter, setter függvényeim megvoltak, avagy a private nem volt gond.
A gond valójában az, hogy levágja a leszármaztatott osztályok extra tagjait, és azokat lekérdezve mindig null.
Rakjál fel egy github/gist linket
Avagy nekem az a különbség, hogy a konstruktoroknál minden paraméter "final". Lehet, hogy ez a gond?
Továbbra sem működik.
Az a baj, hogy nem tudom törölni a "final"-okat a konstruktorokból, mert az IntelliJ fejlesztőkörnyezet visszarakja őket.
Elméletileg állítható valahol; ne kérdezd hogy hol, SODD vagy Google Driven Development megoldja neked is :)
A final nem szabad, hogy gond legyen. Csak annyit jelent, hogy egyszer lehet (és kell?) neki értéket adni. Azon kívül úgy viselkedik, mint egy normál "változó" (final Javaban == példány konstans; static final == típus konstans)
Szerk: ne téveszd el az ==-t és a .equals()-t. Előbbi a referenciát hasonlítja, azaz ugyanaz az objektum-e, míg az utóbbi az objektum tulajdonságait, amit egy @Override equals()... felüldefiniálással tudsz testre szabni.
Lehet ezt amúgyis tudtad, de gondoltam megemlítem :) Tipikus hiba lehetőség, mikor az ember Java-t tanul.
Fun fact: _ha_ _konstans_ stringet hasonlítasz változóhoz, ird így:
Ez azért jó, mert a konstans string .equals()-ja null-safe, szóval nem kapsz NPE-t, csak false-t, ha az_en_valtozom null. Ha fordítva írod és az_en_valtozom null, akkor NPE és gyász van.
Avagy, ha az_en_valtozom null, akkor
Mert egy "null object"-nek, azaz egy sehova se mutató referenciának nincsenek függvényei, mert ugye nem mutat semmilyen objektumra.
.equals vs. == temahoz az a kedvencem, hogy asszem a -128 es +127 kozotti Integereket a futtatokornyezet inditasakor letrehozza performancia okokbol. Szoval megirod a jo kis, ==-ket tartalmazo kododat, kiprobalod (nyilvan kis szamokkal), mukodik, tokeletes. Aztan egyszer csak nem mukodik. (nem futottam bele, de valahol olvastam, es megtetszett :) )
A strange game. The only winning move is not to play. How about a nice game of chess?
Azaz! :)
Szerintem én se futottam még bele, de ez azért eléggé idegesítő dolog. Ezért _sem_ szeretem a Java-t (bár más okokból nagyon is), mert nagyjából minden ésszerű, de az ilyen baromságokkal elrontják a konzisztenciát.
Ami még nem tetszik (de más oldalról nagyon is), az a Spring és egyéb frameworkok. Elrejtik az implementációt. Ami nagyon jó, mert convention over configuration meg ilyenek, de a nap végén az egész csak magic.
Ezzel szoktam interjúztatni.
Objects#equals(Object, Object)
itt még le is fordul: https://onlinegdb.com/By4RW1TH_
@ntamas1, valami hasonló online Javas fordítós helyre rakd össze azt a minimum példát, ami fordul, de szerinted hibás, s megnézzük. ;)
javaban az Object olyan mint C-ben a pointer, az mutathat barmilyen tipusra.
szoval egy Object tipusu tombot csinalj, es abba azt rax amit akarsz :)
Ooo, talán inkább ne :)
Pedig ezt kérte a topic nyitó, a toString meg majd csak visszaad valami értelmeset, vagy nem :)
Igazán leírhatnád, hogy mi volt a konkrét gond, példakóddal együtt, az utókornak :)
A negatív emberekkel ne törődj, nem érdekes a code style, ha beléd kötnek, majd beléjük kötök.
De az eredeti problémát és a megoldást mindenképp illendő leírni, hadd tanuljon belőle az is, aki 2 hét, 2 hónap, 2 év múlva találja meg ezt a topicot.
Wisdom of the Ancients