OOP Fehler im Design

[thelegend27]

Hallo Forum,

Ich habe mich nun gewagt ein Schachspiel in Java zu programmieren. Leider ist mir folgende Dummheit passiert:
Als Basisklasse für alle Spielfiguren sollte die abstrake Klasse dienen:

package chess;

/**
*
*/
public abstract class Meeple {

    private java.awt.Point location;
    private String color;
    private boolean isIngame;

    public void moveTo(java.awt.Point destination) {

    }

    public java.awt.Point[] canMoveTo() {
        java.awt.Point[] points = null;
        return points;
    }
}

Leider ist mir aufgefallen, dass ich die Attribute bei einer Unterklasse nicht ändern kann, da diese private sind.

Nun meine Frage:
Wie sollte ich dieses Problem lösen? Die abstrake Klasse abschaffen, die Attribute auf protected stellen oder eine andere Lösung?

Mit freundlichen Grüßen,
thelegend27

 

[Meniskusschaden]

Du könntest dafür in der abstrakten Klasse eine Methode vorsehen, die du auf protected stellst.

 

[mrBrown]

Welche der beiden Methoden soll denn überhaupt von den Subklassen implementiert werden, und auf welche Variablen ist dafür Zugriff nötig?

 

[thelegend27]

Beide Methoden sollen implementiert werden. Aber um die gehts eigentlich nicht. Ich brauch beispielsweise location und color um bestimmen zu können wohin die Figur hingehen kann. Wenn eine weißen Figur eine andere weiße Figur blockiert muss das berücksichtigt werden. Und um die Position zu wechseln braucht man ja auch schon location.

Meniskusschaden meinst du getter/setter? Habe nicht ganz verstanden, was du mir geraten hast

 

[mrBrown]

Meniskusschaden meinst du getter/setter? Habe nicht ganz verstanden, was du mir geraten hast

Ja, Getter wären das passende dafür.
Die Werte brauchst du ja auch nicht nur in den Unterklassen, sondern auch außerhalb.

 

[thelegend27]

Aso ok, dann dankeschön für die Hilfe

 

[thelegend27]

Habe nun den Vorschlag umgesetzt, weiss aber nicht ob das ganz legal ist was ich da gemacht hab.
Hier die abstrakte Hauptklasse:

public abstract class Meeple {

    private java.awt.Point location;
    private String color;
    private boolean Ingame;

    public void moveTo(java.awt.Point destination) {

    }

    public java.awt.Point[] canMoveTo() {
        java.awt.Point[] points = null;
        return points;
    }

    protected java.awt.Point getLocation() {
        return location;
    }
    protected String getColor(){
        return color;
    }
    protected boolean isIngame(){
        return Ingame;
    }
   

    protected void setLocation(java.awt.Point location) {
        this.location = location;
    }
    protected void setColor(String color){
        this.color = color;
    }
    protected void setIngame(boolean Ingame){
        this.Ingame = Ingame;
    }

}

Und hier eine Unterklasse:

public class King extends Meeple {
    King(java.awt.Point location,String color){
    setLocation(location);
    setColor(color);
    setIngame(true);
   
    }
   
    @Override
    public void moveTo(java.awt.Point destination) {

    }

    @Override
    public java.awt.Point[] canMoveTo() {
        java.awt.Point[] points = null;
        return points;
    }
}

Ist das ordentlich gelöst?

 

[mrBrown]

Erstell in der Abstrakten klasse besser einen Konstruktor, der dann von der Unterklasse aufgerufen wird.

Und die zu überschreibenden Methoden solltest du als abstract markieren

 

[thelegend27]

Erstell in der Abstrakten klasse besser einen Konstruktor, der dann von der Unterklasse aufgerufen wird.

Und die zu überschreibenden Methoden solltest du als abstract markieren

Ich dachte immer abstrakte Klassen dürfen keine Konstruktoren haben, da man keine Exemplare davon bilden soll. Was hab ich dann eigentlich davon, dass ich die Klasse abstract gemacht hab?
EDIT: sry letzte frage war nicht klug. Sie ist natürlich abstract damit ich sie verschieden implementieren kann, oder?

 

[mrBrown]

Nicht der Konstruktor entschiedet dabei über Instanziierbarkeit, sondern abstract

abstract bedeutet, dass du keine Instanz direkt erstellen kannst und abstract (und damit nicht implementierte) Methoden haben kann