NullPointerException aber warum

[Drake]

Hallo zusammen

stehe leider vor einem Problem was sich meinem Verständniss entzieht.

Habe folgende Klasse:

public class MapData {
	public String name = "";
	public String ownerName = "";
	public int ownerId = 0;
	public int imageId = 0;
	public boolean movement = false;
	public int movePenalty = 0; //%
	public boolean wood = false;
	public boolean grain = false;
	public boolean deer = false;
	public boolean fish = false;
	public boolean wine = false;
	public boolean stone = false;
	public boolean ore = false;
	public boolean coal = false;
}

erzeuge mein Objekt und möchte darauf zugreifen:

MapData[][] mapDataTest = new MapData[10][10];
	System.out.println(mapDataTest[1][1].name);

was zur "NullPointerException" führt.

mfg
Drake

 

[nEp]

Das liegt ganz einfach daran, dass du nur ein Array selbst für die MapData Objekte erzeugt hast, aber nicht die einzelnen konkreten MapData Objekte in deinem Array.

MapData[][] mapDataTest = new MapData[10][10];
for (int i=0; i<10; i++)
   for (int j=0; j<10; j++)
         mapDataTest[i][j] = new MapData();
.....

Jetzt funktioniert das. Deine Klasse ist ausserdem aber nicht schön, und dein Array ist auch nicht gerade sinnvoll...

 

[L-ectron-X]

Du hast doch bisher nur ein zweidimensionales Array vom Typ MapData erzeugt und die Dimensionen festgelegt.
Da noch keine MapData-Objekte im Array abgelegt wurden, wird beim Zugriff auf einen leeres Array-Feld eine NullPointerException geworfen.

 

[Drake]

OK danke, Denkfehler meinerseits, ging davon aus, dass wenn ich Array daraus erzeuge die Objekte automatisch erstellt werden würden da es ja ein Array von Objekten ist.

Jetzt funktioniert das. Deine Klasse ist ausserdem aber nicht schön, und dein Array ist auch nicht gerade sinnvoll...

könntest du das bitte weiter erläutern

Ist aus meiner Sicht gar nicht so schlecht eine Map so zu verwalten.

mfg
Dake

 

[Ark]

@Drake: Ich denke, er (sie?) meint, dass bestimmte Informationen wahrscheinlich auf die gesamte Karte zutreffen, sie aber auf jedem Feld(!) erneut gespeichert werden.

Du solltest also noch mal alle möglichen Zustände eines MapData-Objektes durchgehen und überlegen, welche Informationen wirklich nur das einzelne Feld betreffen, und vor allem, ob alle boolean-Werte zugleich true sein können (oder ob doch immer nur einer von diesen boolean-Variablen zu einer Zeit auf true gesetzt ist).

MfG
Ark

 

[Drake]

Ich denke, er (sie?) meint, dass bestimmte Informationen wahrscheinlich auf die gesamte Karte zutreffen, sie aber auf jedem Feld(!) erneut gespeichert werden.

Jeder Eintrag im Array steht für ein Hex-Feld. Aus diesem Array lasse ich Karte(nausschnitte) zeichnen. Einige zusammenhängende Flächen haben natürlich so gut wie die gleichen Werte, doch alles in allem schaut die engültige Karte schon sehr vielfältig aus.

Somit erscheint das mir die komfortabelste Methode, da ich aus jedem Feld alles und nichts machen kann. Dieses hat aus meiner Sicht den Vorteil, dass obwohl ca. 80% Prozent der Karte aus strd. Feldern bestehen (Felder, Berge, ect.) ich die Möglichkeit habe, 'special Felder' mit belibiegen Eigenschaften zu definieren.

Zurzeit mache ich noch meinen Mapeditor fertig, um mich dann weiter dem eigentlichen Spiel zu widmen.

Das ist mein Gedankengang dazu, wobei ich mich über Kritik (pos. wie auch neg.) dessen freuen würde.

mfg
Drake

 

[Ark]

public class MapData {
	public String name = "";
	public String ownerName = "";
	public int ownerId = 0;
	public int imageId = 0;
	public boolean movement = false;
	public int movePenalty = 0; //%
	public boolean wood = false;
	public boolean grain = false;
	public boolean deer = false;
	public boolean fish = false;
	public boolean wine = false;
	public boolean stone = false;
	public boolean ore = false;
	public boolean coal = false;
}

1. Alle Eigenschaften sollten private (oder protected) sein.
2. Welche Werte können movePenalty, ownerId und imageId annehmen?
3. Gibt es einen Zusammenhang zwischen ownerId und imageId?
4. Gibt es einen Zusammenhang zwischen movePenalty und movement?
5. Die Eigenschaften wood, grain, deer, fish, wine, stone, ore und coal solltest Du alle in einem Byte unterkriegen. Da ein boolean 1 Byte belegt, ist es ziemlich kostspielig, mehrere boolean-Werte in zu verwenden, wenn hunderte Objekte dieser Art angelegt werden.

Hier mal mein Vorschlag dazu:

public class MapData {
	private static final byte WOOD = 1;
	private static final byte GRAIN = 2;
	private static final byte DEER = 4;
	private static final byte FISH = 8;
	private static final byte WINE = 16;
	private static final byte STONE = 32;
	private static final byte ORE = 64;
	private static final byte COAL = -128;

	private String name = "";
	private String ownerName = "";
	private int ownerId = 0;
	private int imageId = 0;
	private boolean movement = false;
	private int movePenalty = 0; //%
	private byte set = 0;
}

Aus den booleans habe ich set gemacht. Hier eine Skizze zur Verwendung (falls Dir Binärarithmetik nicht geläufig sein sollte):

// Eigenschaft WOOD setzen
set |= WOOD;

// Eigenschaft WOOD löschen
set &= ~WOOD;

// auf WOOD testen
if((set & WOOD)!=0) …

// auf nicht-WOOD testen
if((set & WOOD)==0) …

// auf nur-WOOD testen
if(set==WOOD) …

// usw.

Ich hoffe, ich bin nicht zu kleinlich. ^^

MfG
Ark

EDIT:
Noch etwas: Hat diese Klassen eigentlich auch Methoden? Oder soll sie nur die Daten bereithalten? Wenn Letzteres zutrifft, sollten die Eigenschaften in der Klasse doch public sein, aber die Klasse selbst sollte innerhalb einer anderen liegen und selbst private (und static) sein, etwa so:

public class MyMap{
	private static class MapData {
		public static final byte WOOD = 1;
		public static final byte GRAIN = 2;
		public static final byte DEER = 4;
		public static final byte FISH = 8;
		public static final byte WINE = 16;
		public static final byte STONE = 32;
		public static final byte ORE = 64;
		public static final byte COAL = -128;

		public String name = "";
		public String ownerName = "";
		public int ownerId = 0;
		public int imageId = 0;
		public boolean movement = false;
		public int movePenalty = 0; //%
		public byte set = 0;
	}
}

Na ja, um die richtige Struktur auszuwählen, müsste man jetzt mehr Informationen darüber haben. Dennoch seien die genannten Dinge zumindest als Denkanstoß zu sehen.

MfG
Ark

 

[Gast]

statt dem set lieber ein enum benutzen, ist viel besser zulesen

 

[Drake]

Danke werde mir das gleich in Ruhe durch den Kopf gehen lassen, möchte jetzt aber schon mal auf deine Punkte eingehen.

1. Alle Eigenschaften sollten private (oder protected) sein.
2. Welche Werte können movePenalty, ownerId und imageId annehmen?
3. Gibt es einen Zusammenhang zwischen ownerId und imageId?
4. Gibt es einen Zusammenhang zwischen movePenalty und movement?
5. Die Eigenschaften wood, grain, deer, fish, wine, stone, ore und coal solltest Du alle in einem Byte unterkriegen. Da ein boolean 1 Byte belegt, ist es ziemlich kostspielig, mehrere boolean-Werte in zu verwenden, wenn hunderte Objekte dieser Art angelegt werden.


zu:
1 Ja, die Klasse soll wirklich nur die Daten beinhalten, darum habe ich der einfachheit halber auf getter und setter verzichtet, was ehrlich gesagt wirklich nur aus Faulheit geschehehen ist. Den Sinn die Klasse public in eine private zu packen erkenne ich jetzt noch nicht (fehlt wohl noch meine min. Kaffeedosis / Morgen)

2. movePenalty muss wirklich ein int sein, da ich einen Wertebereich von 0 - 999 haben möchte
ownerId ist auch einen großen Wertebereich angewiesen, für imageId dagegen sollte ein byte komplett ausreichen

3 nein, ownerId ist der User, dem das Feld 'gehöhrt', imageId beschreibt durch welches Bild das Hexfeld dargestellt wird

4 auch optimierbar, wenn man sich auf / durch das Feld nicht bewgegen kann, ist es unwichtig was für einen Abzug das Feld verursacht auf die strd. Bewegung pro Zeiteinheit

5 die Idee hat was
oder sagen wir mal ist ein verdammt guter Vorschlag zur Optimierung, diese Werte in ein byte zu packen und einfach auszuwerten welche bits alles gesetzt sind um daraus dann auf die Eigenschaften zu schließen, im best case wird so nur ein achtel des Speichers benötigt, was bei einer großen Map doch sehr viel ausmacht.

Keine Sorge, wenn ich das so sehe leuchtet es mir auch ein, obwohl ich beim 'mich rein denken' doch kurz überlegen musste, warum -128, bis ich doch die Stimme in meinem Kopf nicht mehr leugnen konnte, die versuchte mir einzuhämmern, erstes bit gesetzt => negativ, erstes bit gesetzt => negativ

Dein Gedankengang ist auf jedenfall eine Hilfe, und leider kann man streng genommen nicht kleinlich genug.

Jetzt muss ich aber erst einmal neuen Kaffe besorgen.

mfg
Drake

 

[Ark]

Ich kenne mich mit enums für diese Zwecke nicht aus. *zugeb* Wie sieht das denn dann aus?

EDIT:
Eine Eigenschaft eines Objektes sollten immer direkt oder indirekt private (oder protected) sein, es sei denn, jede Klasse bzw. Instanz darf zu jeder Zeit dieser Eigenschaft jeden ihr möglichen Wert (festgelegt durch den Datentyp und die Sprachspezifikation) zuweisen. (Das dürfte wohl recht selten der Fall sein. )

Ansonsten sieht es bis jetzt so aus:
Für movement gilt also zu jeder(!) Zeit

movement == (movePenalty!=0)

richtig?

Für movePenalty sollte ein short genügen. Frage: Reicht ein short (-32768 - 32767) auch für ownerId und/oder imageId?

Gibt es sonst noch irgendwelche Zusammenhänge zwischen den Daten (z. B. zwischen imageId und der von mir vorgeschlagenen Variable set)?

 

[Drake]

Ansonsten sieht es bis jetzt so aus:
Für movement gilt also zu jeder(!) Zeit

movement == (movePenalty!=0)

richtig?

nicht ganz, movementPenalty ist ein Prozentsatz um den sich die Bewegungszeit erhöht, movementPenalty = 0 sollte eigentlich bedeuten, dass bei Bewegung über das Feld sich die benötigte Zeit um 0% erhöht.

Wobei der Ansatz natürlich auch was hat, somit bestünde zwar immer eine Verzögerung von einem Prozent, aber wenn die Verzögerung 0% wäre, würde daraus folgen Bewegung auf diesem Feld nicht möglich, spart somit ein weiteres byte.

Ich gebe zu, ich weiss auch nicht was mich geritten hat in der MapData Klasse alles public zu machen.

imageId steht in keiner Beziehung zum Rest, den optischen Hintergrung weise ich im Mapeditor zu, jedoch können Felder mit den gleichen Werten durchaus unterschiedliche Hintergrundbilder haben, je nach dem welche Felder um sie herum sind.

Ja, short wäre für imageId wohl der geeigneste Datentyp, ownerId muss aber int bleiben, kann dir den Sinn dessen aber nur in einer pn erläutern.

Doch leider habe ich anscheinend zur Zeit keinen Kopf für die passenden Datentypen, liegt daran, dass ich für meine Grundlagen der Algorithmen und Datenstrukturen Klausur am Do am lernen bin und in meinem Kopf die verschiedensten Sortieralgorithmen mit Laufzeiten rum spucken gepaart mit Bäumen.

 

[Ark]

Wenn also doch kein wirklicher Zusammenhang zwischen movePenalty und movement besteht, kannst Du movement zumindest wie folgt verbauen, um kein Byte extra dafür zu verbraten:

private static final short MOVEMENT = 16384;
private static final short MOVE_PENALTY = 16383;

private short moveAndPen = 0;

// Es gelten:
// movement == moveAndPen & MOVEMENT
// movePenalty == moveAndPen & MOVE_PENALTY

Mit anderen Worten: Das oberste Bit von moveAndPen wird als movement-Ersatz benutzt, die unteren 15 Bits als movePenalty. Dies ist recht einfach möglich, da ja movePenalty nie negativ wird.

Das Vorgehen zum Testen auf movement ist äquivalent zu dem, was ich oben bereits beschrieb. Du musst nur beachten, dass Du für movePenalty immer moveAndPen & MOVE_PENALTY angibst!

MfG
Ark

 

[Drake]

Ok

dadurch kann ich meine MapData doch sehr schön optimieren, muss mich zwar was die lesbarkeit immer wieder reindenken, aber das ist es Wert, da so mehr als die Hälfte des Speichers eingespart wird, danke dir.

mfg
Drake

 

[Ark]

@Drake: Hoffentlich guckst Du trotz Paranoia auch ab und zu in Dein PN-Fach.

MfG
Ark

 

[Drake]

Bin doch auch nur ein kleiner Student der nebenbei noch arbeiten geht, bitte nicht übel nehmen, kann doch nichts dafür, dass ich noch kein passendes Mittel gegen dieses merkwürdige "Schlaf-Phänomen" gefunden habe ,
aber ich arbeite dran :lol: