[JAVA] probleem met array van classes

[Arnold|IA]

Ik ben bezig om JAVA onder de knie te krijgen de volgende classes heb ik geschreven:

class Main

code:

public static void main(String[] args) {
        System.out.println("Welkom bij Zeeslag");
        Bord blaat = new Bord();
        if(blaat.setBord(1)){
            System.out.println("Bord " + blaat.getBord() + " is aangemaakt.\n");
        }
        blaat.testbord();
}

class spelbord

code:

class spelbord {
    int[][] speelbord = new int [10][10];   
    public void setwaardes(){
        for (int i=0; i<speelbord.length; i++){
            for (int j=0; j<speelbord[i].length; j++){
                speelbord[i][j]=0;
            }
        }
    }
}

Class Bord

code:

public class Bord {
static spelbord[] speelveld = new spelbord[2];
int bordnummer=0;
    public boolean setBord(int i){
        bordnummer=i;
        if (bordnummer != 0){
             this.speelveld[bordnummer].setwaardes();

            return true;
        } else {
            return false;
        }
        

        
    }
    public int getBord(){
        return bordnummer;
    }
    public void testbord(){
        for (int j=0; j < 10; j++){
            for (int k=0; k < 10; k++){
                System.out.println("De waarde van X en Y "+ j + "," + k +"  is " + speelveld[bordnummer].speelbord[j][k]);
            }
        }
    }
}

Graag wil ik dat spelbord static beschikbaar is in mijn applicatie vandaar dat ik een static spelbord[] aanmaak in de class bord.

De uitvoer van Main gaat hier mis:
Bord blaat = new Bord();
if(blaat.setBord(1)){

blaat.setBord gaaeft op regel 7 van de class Bord deze foutmelding:
java.lang.NullPointerException

De waardes van de variabelen zijn op moment dat deze regel wordt uitgevoerd:
bornummer type int waarde 1
speelveld type spelbord[] length = 2
spelbord[0] waarde null
spelbord[1] waarde null


Er worden 2 spelborden aangemaakt maar deze worden naar mijn idee niet geinitialiseerd ik kan ze niet gebruiken.

Waarschijnlijk zie ik iets over het hoofd of vergeet ik iets.
Wie kan me vertellen wat ik fout doe, ik ben hier nu al tijden mee bezig om dit op te lossen en heb al veel informatie opgezocht hierover met google maar kom niet verder.

[Alarmnummer]

De array wordt aangemaakt, maar de objecten in de array zitten worden niet aangemaakt.

Dus
Persoon[] x = new Persoon[7];
hierbij wordt dus geen enkel persoon aangemaakt (alleen een array met 7 plaatsen waar een persoon kan komen te staan)

Pas als je dit doet:

code:

for(int k=0;k<x.length;k++){
    x[k]=new Persoon(....);
}

dan wordt de array gevuld met echte personen.

[ Voor 21% gewijzigd door Alarmnummer op 18-10-2005 13:12 ]

[Apie!]

Je initialiseert een array van Spelbord met een grootte van 2, maar de objecten zelf moet je nog instantieren. Je hebt de ruimte om de speelborden in op te slaan gemaakt, maar nu nog de speelborden zelf zeg maar.

-spuit 11-

[ Voor 4% gewijzigd door Apie! op 18-10-2005 13:11 ]

[Hydra]

Inderdaad heb je alleen een array geallocceerd, maar daar geen objecten ingehangen. Als je een array alloceerd is deze leeg, een Spelbord[] array van 2 groot zal dus gewoon twee keer 'null' bevatten.

Nu we toch bezig zijn, een paar dingetjes:

Java:

public class Bord {
static spelbord[] speelveld = new spelbord[2];
int bordnummer=0;
    public boolean setBord(int i){
        bordnummer=i;
        if (bordnummer != 0){
             this.speelveld[bordnummer].setwaardes();

            return true;
        } else {
            return false;
        }
    }
    public int getBord(){
        return bordnummer;
    }
    public void testbord(){
        for (int j=0; j < 10; j++){
            for (int k=0; k < 10; k++){
                System.out.println("De waarde van X en Y "+ j + "," + k +"  is " + speelveld[bordnummer].speelbord[j][k]);
            }
        }
    }
}

Je gebruikt redelijk lukraak hoofd/kleine letters; leer jezelf aan classes te UpperCases en methodenamen te camelCasen. Verder heb je een static array waar je die twee speelborden in wil stoppen, tenzij je er redenen voor hebt hoor je je members te encapsulaten; maak daar dus een private array van i.p.v. default static.

[Robtimus]

Arnold schreef op dinsdag 18 oktober 2005 @ 13:05:

code:

class spelbord {
    int[][] speelbord = new int [10][10];   
    public void setwaardes(){
        for (int i=0; i<speelbord.length; i++){
            for (int j=0; j<speelbord[i].length; j++){
                speelbord[i][j]=0;
            }
        }
    }
}

De waardes in een array zijn, direct na het creeren van het array dmv new, 0 voor getallen (en chars), false voor booleans en null voor ALLE objecten. Deze initialisatie is dus niet nodig.

code:

public class Bord {
static spelbord[] speelveld = new spelbord[2];
int bordnummer=0;
    public boolean setBord(int i){
        bordnummer=i;
        if (bordnummer != 0){
             this.speelveld[bordnummer].setwaardes();

            return true;
        } else {
            return false;
        }
    }
}

Even een test voor je: wat gebeurt er als i geen 0 of 1 is?

[pjvandesande]

IceManX schreef op dinsdag 18 oktober 2005 @ 14:17:
Even een test voor je: wat gebeurt er als i geen 0 of 1 is?

Returned hij gewoon false.

Een assert erbij zou leuk zijn

[Jochem Knoops]

questa schreef op dinsdag 18 oktober 2005 @ 14:58:
[...]


Returned hij gewoon false.

Een assert erbij zou leuk zijn

Oke, alvast een tip, hij return niet false maar geeft een exception.

Nu mag questa of de TS uitleggen waarom dan een exception

[ Voor 11% gewijzigd door Jochem Knoops op 18-10-2005 15:00 ]

[Robtimus]

JochemKnoops schreef op dinsdag 18 oktober 2005 @ 15:00:
Oke, alvast een tip, hij return niet false maar geeft een exception.

Juistem
Je kan zelfs exact noemen welke exception.

[pjvandesande]

JochemKnoops schreef op dinsdag 18 oktober 2005 @ 15:00:
[...]


Oke, alvast een tip, hij return niet false maar geeft een exception.

Nu mag questa of de TS uitleggen waarom dan een exception

Zoals Mike Gunderloy zegt en ik het er nog aardig mee eens ben, Assert gebruik je voor Design Time errors, dit is imho een Design Time error die door een Assert gecontrolleerd zou moeten worden.

De arg bordnummer hoort boven aan de method al gevalideert te worden, daar mag dus wel een Exception worden gegooit een ArgumentOutOfRange oid.

bordnummer mag niet negatief zijn en niet groter dan speelveld.Lengt

[Robtimus]

questa schreef op dinsdag 18 oktober 2005 @ 15:16:
Zoals Mike Gunderloy zegt en ik het er nog aardig mee eens ben, Assert gebruik je voor Design Time errors, dit is imho een Design Time error die door een Assert gecontrolleerd zou moeten worden.

Echter, asserts hoor je niet te gebruiken ter validatie bij niet-private methods. Je mag er namelijk niet van uitgaan dat jij de enige bent die deze code gebruikt, of dat je het niet in andere code gaat hergebruiken. En als je dan vergeten bent (ok, kleine kans...) dat i alleen maar 0 of 1 mag zijn dan heb je een probleem.

De arg bordnummer hoort boven aan de method al gevalideert te worden, daar mag dus wel een Exception worden gegooit een ArgumentOutOfRange oid.

bordnummer mag niet negatief zijn en niet groter dan speelveld.Lengt

Klopt.
Op het moment is er dus een groot risico* op een ArrayIndexOutOfBoundsException. Juist omdat die controle er niet is. Dus of er moet een betere check (return false als i < 0 || i > 1, gooi een eigen exceptie), of je gebruikt de AIOOB Exceptie. VERMELD DIT DAN WEL in je javadoc.


* Niet direct omdat het de code van de TS zelf is, maar in de toekomst misschien wel.


Edit: die AIOOB exceptie gebruiken is trouwens wel een slechte gewoonte - je maakt een deel van je implementatie bekend (nml dat je een array gebruikt). Als je later een List gaat gebruiken wordt het een IndexOutOfBoundsException - dit is al generieker maar toch weer implementatie afhankelijk.
Beter is zelf checken en een IllegalArgumentException gebruiken als i niet geldig is.

[ Voor 14% gewijzigd door Robtimus op 18-10-2005 16:29 ]

[pjvandesande]

IceManX schreef op dinsdag 18 oktober 2005 @ 16:26:
[...]
Echter, asserts hoor je niet te gebruiken ter validatie bij niet-private methods. Je mag er namelijk niet van uitgaan dat jij de enige bent die deze code gebruikt, of dat je het niet in andere code gaat hergebruiken. En als je dan vergeten bent (ok, kleine kans...) dat i alleen maar 0 of 1 mag zijn dan heb je een probleem.

Dat zeg ik, design time.

[Alarmnummer]

IceManX schreef op dinsdag 18 oktober 2005 @ 16:26:
[...]
Echter, asserts hoor je niet te gebruiken ter validatie bij niet-private methods. Je mag er namelijk niet van uitgaan dat jij de enige bent die deze code gebruikt, of dat je het niet in andere code gaat hergebruiken. En als je dan vergeten bent (ok, kleine kans...) dat i alleen maar 0 of 1 mag zijn dan heb je een probleem.

In sommige gevallen heb ik maling aan de regels. Asserts zijn prachtig om hele zware checks mee uit te voeren die in een productie omgeving domweg niet uitgevoerd moeten worden. Ik heb het bv heel zwaar zitten mijn Prolog compiler en het is dan wel fijn als je het aan en uit kunt zitten (met asserts aan draait het systeem op ca 25% van de snelheid).

[Robtimus]

Maar omdat het in een public method gebruikt zou worden is het toch niet correct (volgens de examinatoren van het SCJP examen) om daar assert te gebruiken.
Assert gebruik je alleen maar als je zeker weet dat iets moet gelden, niet als de input van anderen afhankelijk is. En bij public methods is dat toch zo.
Als je nml runt zonder assertions enabled dan wordt deze fout genegeerd en krijg je alsnog een AIOOB exception als i < 0 || i > 1

[pjvandesande]

IceManX schreef op dinsdag 18 oktober 2005 @ 16:33:
En bij public methods is dat toch zo.

Niet altijd:

code:

public void Melp()
{
     Debug.Assert(_conn.State == Open, "Melp message")

     ...
}

[Robtimus]

Ok, kleine correctie dan: op invoer (parameters) controleren dmv assertions in public methods wordt afgeraden. Het zou zelfs verboden moeten worden als je ervan afhankelijk bent omdat de input afhankelijk is van user input in de GUI / command line.

[ Voor 3% gewijzigd door Robtimus op 18-10-2005 16:50 ]

[.oisyn]

IceManX schreef op dinsdag 18 oktober 2005 @ 16:33:
Maar omdat het in een public method gebruikt zou worden is het toch niet correct (volgens de examinatoren van het SCJP examen) om daar assert te gebruiken.

Alsof je een self-contained project volledig gaat peperen met het throwen van exceptions. Ik vind het een beetje krom om als eis te stellen "bij publieke functies". Natuurlijk, de scope waarvandaan een private functie wordt aangeroepen is veel kleiner en heb je meestal zelf in de hand (eigen class). Maar het kan natuurlijk net zo goed een publieke functie zijn van een private class waar verder niemand aan komt, of gewoon code dat simpelweg geen library is.

Maar goed, ik vind een exception bij het verkeerd aanroepen van een functie sowieso iets raars; dat is geen uitzondering, dat is een programmeersfout, en dat evt. gaan lopen afvangen is helemaal van den zotte .

[pjvandesande]

IceManX schreef op dinsdag 18 oktober 2005 @ 16:50:
Ok, kleine correctie dan: op invoer (parameters) controleren dmv assertions in public methods wordt afgeraden. Het zou zelfs verboden moeten worden als je ervan afhankelijk bent omdat de input afhankelijk is van user input in de GUI / command line.

Dan praat je dus alleen over invoer als ik het goed begrijp, dat snap ik ook wel. Dat kun moet je namelijk ook niet met een Assert testen maar gelijk met een IF-ELSE-MessageBox/Schop-User.

[Alarmnummer]

.oisyn schreef op dinsdag 18 oktober 2005 @ 16:52:
[...]

Maar goed, ik vind een exception bij het verkeerd aanroepen van een functie sowieso iets raars; dat is geen uitzondering, dat is een programmeersfout, en dat evt. gaan lopen afvangen is helemaal van den zotte .

Dan houden we wel degelijk een andere filosofie erop na. Ik controleer wel of argumenten deugen want dit bespaard me een pens vol werk doordat je bugs veel sneller op kunt sporen. In java-land is het trouwens ook common-practice om het te doen. Zelfde geld trouwens voor unit testen (waar je uiteraard ook niet aan doet).

[ Voor 11% gewijzigd door Alarmnummer op 18-10-2005 17:56 ]

[.oisyn]

Alarmnummer schreef op dinsdag 18 oktober 2005 @ 17:54:

Dan houden we wel degelijk een andere filosofie erop na. Ik controleer wel of argumenten deugen want dit bespaard me een pens vol werk doordat je bugs veel sneller op kunt sporen.

Ik drukte me wellicht ietwat verkeerd uit. Uiteraard moet je argumenten controleren, maar daar heb je dus asserts voor, geen exceptions. Wat ik van den zotte vond was dat je dergelijke exceptions als user dus weer af kunt vangen. Ja, anders geef je gewoon de goede parameters . Het is dan ook niet nodig om ze af te vangen, en dus ook niet om exceptions te gebruiken maar gewoon asserts

[ Voor 10% gewijzigd door .oisyn op 18-10-2005 18:00 ]

[Robtimus]

.oisyn schreef op dinsdag 18 oktober 2005 @ 16:52:
[...]


Alsof je een self-contained project volledig gaat peperen met het throwen van exceptions. Ik vind het een beetje krom om als eis te stellen "bij publieke functies". Natuurlijk, de scope waarvandaan een private functie wordt aangeroepen is veel kleiner en heb je meestal zelf in de hand (eigen class). Maar het kan natuurlijk net zo goed een publieke functie zijn van een private class waar verder niemand aan komt, of gewoon code dat simpelweg geen library is.

Maar goed, ik vind een exception bij het verkeerd aanroepen van een functie sowieso iets raars; dat is geen uitzondering, dat is een programmeersfout, en dat evt. gaan lopen afvangen is helemaal van den zotte .

Mjah, ik heb net het boek voor Java certificering uit, dus ik ben (tijdelijk) geindoctrineerd

[Alarmnummer]

.oisyn schreef op dinsdag 18 oktober 2005 @ 17:59:
[...]

Ik drukte me wellicht ietwat verkeerd uit. Uiteraard moet je argumenten controleren, maar daar heb je dus asserts voor, geen exceptions.

Dat ligt er dus aan. In java-land is het gebruikelijk om een runtimeexception (lees unchecked exceptions) op te werpen als je foute argumenten meegeeft en deze exceptions moeten ook vermeld staan in je javadoc.

Wat ik van den zotte vond was dat je dergelijke exceptions als user dus weer af kunt vangen. Ja, anders geef je gewoon de goede parameters .

Dat is zo. Runtimeexceptions hoor je over het algemeen niet af te vangen omdat het programmeerfouten zijn (alleen op heel laag nivo pak je ze dus op en onderneem je er acties op).

[ Voor 3% gewijzigd door Alarmnummer op 18-10-2005 18:12 ]

[Verwijderd]

Alarmnummer schreef op dinsdag 18 oktober 2005 @ 18:12:
Dat is zo. Runtimeexceptions hoor je over het algemeen niet af te vangen omdat het programmeerfouten zijn (alleen op heel laag nivo pak je ze dus op en onderneem je er acties op).

Wat bedoel je met "heel laag niveau", Voor bijvoorbeeld webapplicaties pak ik ze tegen de userinterface op (wat mij als hoog in de oren klinkt) om een nette error page te kunnen geven.

[Alarmnummer]

Verwijderd schreef op dinsdag 18 oktober 2005 @ 20:28:
[...]

Wat bedoel je met "heel laag niveau",

Ik had mijn stack ff andersom staan.

Voor bijvoorbeeld webapplicaties pak ik ze tegen de userinterface op (wat mij als hoog in de oren klinkt) om een nette error page te kunnen geven.

Precies.

[pjvandesande]

Alarmnummer schreef op dinsdag 18 oktober 2005 @ 21:02:
[...]

Ik had mijn stack ff andersom staan.

* pjvandesande zet de stack weer normaal

Exceptions zijn makkelijk tijdens runtime, ze zijn goed af te vangen op hoog nivo en daarna te loggen.

Asserts gebruik ik veel de ontwikkel fase, daar vind ik ze veel makkelijker dat exception.

[Robtimus]

Qua werking zijn het anders net exceptions hoor:

Java:

assert guard : statement;

kun je lezen als

Java:

if (!guard) throw new AssertionError(statement);

Want zoals je misschien wel weet gedragen Errors zich net als RuntimeExceptions, je kunt ze zelfs afvangen. Dat is alleen niet de bedoeling, maar het KAN wel

Edit: dit geldt natuurlijk pas als assertions enabled zijn. Anders wordt de hele statement overgeslagen, en daarin verschillen de 2 constructies, en daarom zijn assertions sneller.

[ Voor 22% gewijzigd door Robtimus op 18-10-2005 21:50 ]

[Arnold|IA]

Heren allen bedankt voor deze reacties, ik heb het inmiddels werkend gekregen .

[Confusion]

Iets wat mij opviel: zo'n functie die alle velden in de array op 0 zet, kan je beter 'resetWaardes' oid. in plaats van setWaardes noemen. Het is niet onwaarschijnlijk dat je later alsnog één of andere functie 'setWaarde' wilt noemen en dan wordt het verwarrend.