Probleme mit der Vererbungshierarchie

[MitchGilliam]

Guten Morgen,

ich habe ein kleines Verständnisproblem im Bezug auf Vererbung.
Momentan arbeite ich an einem kleinen Projekt für die Uni; daher kann ich jedoch leider den Quellcode nicht hierher posten und muss es beispielhaft erklären:

1. Klasse Mother:

Diese beinhaltet einige Felder (zumeist int und ArrayList<Point>/ArrayList<boolean[][]) sowie ein paar Methoden, welche z.B. einem der Felder etwas hinzufügen, wegnehmen oder in sonst einer Weise damit arbeiten.
z.B.:

public boolean[][] getBody() {
		return this.pieceRotations.get(rotationActual);
	}

2. Die Tochter Klasse:

Tochter extends Mother:
Und hier beginnen meine Probleme.

Hiervon erzeuge ich nun Objekte - nur von der Tochter, nie von der Mutter
Diese sollte doch alles von Mother erben. Wenn ich nun jedoch von außen, also einem dritten Objekt, nennen wir es Verehrer eine Methode in der Tochter aufrufe, die nur in Mother definiert ist, deren Felder jedoch in der Tochter selbst stehen, bekomme ich eine nullPointerException.

Habt ihr das Problem verstanden?

Danke schonmal an jeden, der sich die Zeit nimmt und dies liest.

Viele Grüße
MG

 

[FArt]

Ich habe ja schon vieles gesehen, aber das solltest du mal live präsentieren.

Schreib mal minimalen Beispielcode. Du darfst die klassen auch A, B und C nennen, damit deine Kollegen dieses hervorragende Stück Software nicht kopieren. ;-)

 

[MitchGilliam]

Hey,

so, tut mir leid, wollte nicht so darstehen, als hätte ich keinen Bock, was zu lernen.
Hier nun ein Beispiel statt meines original-Codes


Meine Oberklasse. Diese beinhaltet das Feld "pieceNumber"

clase MotherPiece{
     private int pieceNumber;
     
     piece (int pieceNumber) {
 
     }

     private int getPieceNumber() {
          return this.pieceNumber;
     }
}

Neun meine Unterklasse. Deren Konstruktor setzt das feld "pieceNumber"

class DaughterPiece extends MotherPiece {
     private int pieceNumber;

     DaughterPiece(int pieceNumber) {
          this.pieceNumber = pieceNumber;
     }
}

Und nun eine Klasse, die Objekte vom Typ DaughterPiece erzeugt.

import DaugterPiece.java
class UsePiece {
     UsePiece(int givenValue) {
          DaughterPiece newPiece = new DaugterPiece(givenValue);
          int j = DaughterPiece.getPieceNumber();
          System.Out.PrintLN("PieceNumber: " + j);
     }
}

Wenn ich nun gehtPieceNumber aufrufe, gibt er mir nicht die PieceNumber der Tochter sondern die der Mutter zurück.
Das ich dies einfach umgehen könnte, indem ich statt

[b]this.pieceNumber = pieceNumber;[/b] => [b][u]super[/u].pieceNumber = pieceNumber;[/b]

schreibe ist mir klar; jedoch arbeite ich in meinem realen Projekt mit wesentlich komplizierteren Feldern, weshalb ich in der Tochter-Klasse mindestens 10 x super schreiben müsste.
Ich finde, dies ist keine schöne Lösung und mir geht auch nicht ganz in den Kram, wieso meine Felder nicht vererbt werden.
Dies würde die Sache enorm erleichtern.
Ich frage mich gerade, wie wohl ein Konstrukt aussehen würde, welches wiederrum von meiner Tochter erbt. Ich hätte ja keine Möglichkeit mehr, überhaupt auf die Felder von MotherPiece zuzugreifen.

Für eure Hilfen wäre ich sehr dankbar.

Grüße
MG[/u]

 

[SlaterB]

in deinem Code wird nie getRotationPoint() aufgerufen, soweit ich das sehe,
soll man sich alle Details selber zusammensuchen?

die Frage nach einem einfachen Testprogramm ist nicht nur eine Frage des Copyrights sondern auch des Verständnisses..

in jedem Fall kann man schon mal sagen, dass Felder nicht vererbt werden,
Felder sollten generell immer private sein, wenn nicht anders möglich,
falls doch mal nicht private, dann sollte auf keinen Fall die Subklasse Felder gleichen Names definieren,
mit solchen krummen Sachen landet man nur im Chaos,

wenn du irgendwas überschreiben willst, dann definiere dir einfache getter-Operationen:
getFeldXY();

die kannst du mit allen Java-Mitteln überschreiben, in Interfacen deklarieren, als abstract vorgeben usw.,

mit Feldern aber bloß nix machen

 

[Marco13]

pieceNumber in der MotherClass könnte protected sein, wenn nichts dagegen spricht. Wenn es aber NUR im Konstruktor gesetzt wird, wäre es ggf. sogar sinnvoller, es private zu machen, und nur den getter anzubieten ... wenn nichts dagegen spricht :roll: