neue Objektnamen durchlaufen

[Nico1999]

Code Schach wenn der Bauer in eine beliebige Figur umgetauscht werden kann hier nur Läufer

public class Bauerb(){
    private int x;//position auf spielfeld
    private int y;
    
    // konstruktor getter und setter sind vorhanden


    public int BauererreichtandereSeite (this.x){
        if (this.x==0){
            System.out.print("zu welcher Figur soll der Bauer werden");
            int a=sc.nextInt();
            if (a==-2){//wird zu Läufer
                Läuferb läuferb3=new Läuferb(this.x, this.y, -2)
            }
        }
    }
    }

Wie kann ich es erreichen, dass ich immer ein neues objekt erstelle also läuferb3 auf läuferb4, wenn ein anderer bauer auch die andere seite erreicht
Kann ich da jetzt irgenteine Variable bestimmen die ich dann bei i=3 und nach der anweisung i++; so das dann das nächste mal läuferb4 rauskommt.

 

[Marinek]

Nein, das geht so nicht.
Du müsstest ja schon ein Array aus Figuren irgendwo haben. Wie Referenzierst du sonst Bauerb?

Da müsstest du noch mehr Quellcode posten, um genauer zu helfen.

Eine Figur sollte auch nicht den tatsächlichen Wechsel durchführen. In deinem Fall müsste es das Board machen, wenn eine Figur, die tauschbar ist, die letzte Reihe betritt.

Bitte beachte ebenfalls die folgenden Hinweise:

1. public int BauererreichtandereSeite (this.x){ // Das ist so nicht kompilierbar. Das this.x muss hier weg.
2. Wofür steht das "b" in der Klasse? Ohne Kontext würde ich sagen das ist "falsch".

 

[mihe7]

@Apple’s Jünger war schneller, das erspart mir einen Kommentar. Trotzdem noch ein Hinweis: wenn Du auf dem Schachbrett die andere Seite erreichst, dann mutiert der Bauer ja auch nicht plötzlich zu einem Läufer, sondern Du nimmst den Bauern weg und stellst dafür einen Läufer hin.

 

[Nico1999]

Nein, das geht so nicht.
Du müsstest ja schon ein Array aus Figuren irgendwo haben. Wie Referenzierst du sonst Bauerb?

Da müsstest du noch mehr Quellcode posten, um genauer zu helfen.

Eine Figur sollte auch nicht den tatsächlichen Wechsel durchführen. In deinem Fall müsste es das Board machen, wenn eine Figur, die tauschbar ist, die letzte Reihe betritt.

Bitte beachte ebenfalls die folgenden Hinweise:

1. public int BauererreichtandereSeite (this.x){ // Das ist so nicht kompilierbar. Das this.x muss hier weg.
2. Wofür steht das "b" in der Klasse? Ohne Kontext würde ich sagen das ist "falsch".

ich habe eine oberklasse Figur kann ich da irgentwie einen array aus denen machen und da auch die unterklassen dann daraus machen
ich werde den code nochmal so umschreiben figur, dass bewegen vom brett ausgeht und nicht von der figur
warum ist this.x nicht kompilierbar verstehe ich nicht
das b steht für schwarz also bauer schwarz
könntest du mir mal zeigen wie man das mit den array aus figuren macht, wenn figur die oberklasse ist und bauer schwarz bsp die unterklasse
und wenn ich alles vom brett ausmache brauche ich dann überhaupt noch eine klasse figur ?
und kann ich da in dem array von figuren dann einfache eine bauern klasse zur damen klasse machen ?

 

[Gelöschtes Mitglied 65838]

BauererreichtandereSeite (this.x)

das ist kein übergabe parameter... so schreibt man methoden nicht!

 

[mihe7]

ich habe eine oberklasse Figur kann ich da irgentwie einen array aus denen machen und da auch die unterklassen dann daraus machen

Du kannst ein Figur-Array erstellen und dort Objekte ablegen, die eine Instanz der Klasse Figur oder einer ihrer Subklassen ist.

das b steht für schwarz also bauer schwarz

Die Farbe ist lediglich ein Attribut, dafür brauchst Du keine Klasse.

und wenn ich alles vom brett ausmache brauche ich dann überhaupt noch eine klasse figur ?

Ja. Ein Spielbrett hat andere Aufgaben als eine Figur.

Du könntest z. B. sagen, dass eine Figur einen Typ und eine Farbe hat.

Mit aktuellem Java lässt sich z. B. schreiben:

public record Figur(Typ typ, Farbe farbe) {
    public enum Typ { BAUER, TURM, SPRINGER, LAEUFER, DAME, KOENIG }
    public enum Farbe { SCHWARZ, WEISS }
}

 

[KonradN]

Also erst einmal solltest Du Klassen sauber definieren.

Wenn ich mir das so ansehe, dann sehe ich Autos. Diese haben natürlich ein Attribut Farbe.
Aber es sind alles Autos und nicht AutoBlau, AutoSchwarz und so!

So macht es auch bei Dir Sinn, das Klassendesign zu überdenken. So könntest Du etwas haben wie:
- Klasse Figur, eine Figur hat eine Farbe wobei Farbe ein Enum ist aus WEISS, SCHWARZ
- Eine Figur kann sich bewegen - hier ist die Frage, was Du für ein Interface definierst. Evtl. etwas wie List<Field> getTargetFields().

Das ist dann eine Methode, die evtl. abstrakt ist und dann bei allen Unterklassen geschrieben werden muss. Das ist aber nur eine Option - es kann auch sein, dass man da etwas nutzt wie das Command Pattern, d.h. Figur ist schon eine Endklasse, von der nicht mehr abgeleitet wird und die Figur hat ein Typ (Was wieder ein Enum ist: BAUER, TURM, SPRINGER, ....)

Das Enum selbst kann dann z.B. das jeweilige Verhalten widerspiegeln.

Dein Problem mit dem "Figurentausch" wäre dann auch trivial: Das wäre dann kein Herausnehmen eines Bauern und ersetzen durch einen anderen Bauern sondern wäre dann einfach die Zuweisung eines anderen Typs.

Wichtig aber als erstes - ehe man irgend einen Code schreibt - dass man sich genau überlegt: Was für Klassen gibt es? Welche Attribute brauchen diese? Und das kann dann durchaus im ersten Schritt sein: Es gibt ein Spielbrett mit Figuren und dann irgend eine Aufteilung um Bauern, Springer, ... abzubilden. Ob und wie man da Vererbung anwendet ist da fast nebensächlich.

 

[Nico1999]

Mit aktuellem Java lässt sich z. B. schreiben:

public record Figur(Typ typ, Farbe farbe) {
    public enum Typ { BAUER, TURM, SPRINGER, LAEUFER, DAME, KOENIG }
    public enum Farbe { SCHWARZ, WEISS }
}

Leider weiß ich nicht was record bedeuten soll, die anderen anworten von dir haben mir sehr weiter geholfen

- Eine Figur kann sich bewegen - hier ist die Frage, was Du für ein Interface definierst. Evtl. etwas wie List<Field> getTargetFields().
Wichtig aber als erstes - ehe man irgend einen Code schreibt - dass man sich genau überlegt: Was für Klassen gibt es? Welche Attribute brauchen diese? Und das kann dann durchaus im ersten Schritt sein: Es gibt ein Spielbrett mit Figuren und dann irgend eine Aufteilung um Bauern, Springer, ... abzubilden. Ob und wie man da Vererbung anwendet ist da fast nebensächlich.

danke für deinen Tipp ich werde das ganze jetzt nochmal ganz neu machen könntet ihr vllt nochmal kurz gucken ob mein neuer Ansatz von Figur passt danke schonmal.
[CODE lang="java" title="Figur"]public class Figur {
private enum farbe{schwarz, weiß};
private enum typ{Bauer, König, Dame, Läufer, Turm, Pferd}
private int x;
private int y;
private int wert;
private int graphik;

} // geter seter konstruktor
public boolean legalmove(int schachbrett [][], int eingabe){
// schaue ob move möglich ist
}
public class Schachbrett{
private int[8][8]schachbrett;
//brauch ich hier einen konstruktor? in spielbeginn setzte ich ja quasi das
// spielfeld erst auf
public int[][] figurbewegen(int[][], int eingabe){
// bewege figur
}public int [][] spielbeginn(int[][]){
// mache anfangs aufstellung oder sollte man gleich
}

}public class spieler{
private enum farbe{schwarz, weiß};
public boolean ichbindran(int moveanzahl){
// bestimmme ob ich dran bin
}public boolean gewinner(int[][], int eingabe){
// bestimme ob könig fehlt
}
}[/CODE]

 

[KonradN]

Derzeit hast Du in den Klassen Enum typen definiert: Das hat zum Ergebis, dass die Instanzen kein entsprechendes Attribut hast und zum anderen hast du Zwei Enums: spieler.farbe und Figur.farbe

=> Klassen / Enums starten mit einem großen Buchstaben.
=> Wenn möglich immer alle Klassen / Enum als public innerhalb einer eigenen Datei definieren. Innere Klassen und so nur verwenden, wenn diese explizit nur innerhalb der Klasse verwendet werden sollte und nach außen keine Bedeutung hat. (Also am Anfang am Besten ganz sein lassen.)

Wenn Du das Enum Farbe erstellt hast, dann hast Du in der jeweiligen Klasse ein Attribut wie private Farbe farbe;

 

[Nico1999]

Derzeit hast Du in den Klassen Enum typen definiert: Das hat zum Ergebis, dass die Instanzen kein entsprechendes Attribut hast und zum anderen hast du Zwei Enums: spieler.farbe und Figur.farbe

=> Klassen / Enums starten mit einem großen Buchstaben.
=> Wenn möglich immer alle Klassen / Enum als public innerhalb einer eigenen Datei definieren. Innere Klassen und so nur verwenden, wenn diese explizit nur innerhalb der Klasse verwendet werden sollte und nach außen keine Bedeutung hat. (Also am Anfang am Besten ganz sein lassen.)

Wenn Du das Enum Farbe erstellt hast, dann hast Du in der jeweiligen Klasse ein Attribut wie private Farbe farbe;

danke

 

[mihe7]

Leider weiß ich nicht was record bedeuten soll, die anderen anworten von dir haben mir sehr weiter geholfen

Ein record ist "syntaktischer Zucker" für eine Klasse, die aus unverändlichen Daten besteht, damit man nicht so viel tippen muss

Zum Vergleich: um das gleiche bzw. ein ähnliches Ergebnis wie mit dem record oben zu erreichen, müsstest Du schreiben

import java.util.Objects;

public class Figur {
    public enum Typ { BAUER, TURM, SPRINGER, LAEUFER, DAME, KOENIG }
    public enum Farbe { SCHWARZ, WEISS }

    private final Typ typ;
    private final Farbe farbe;

    public Figur(Typ typ, Farbe farbe) {
        this.typ = typ;
        this.farbe = farbe;
    }

    public Typ typ() { return typ; }
    public Farbe farbe() { return farbe; }

    public boolean equals(Object obj) {
        if (obj == null || obj == this || !(obj instanceof Figur)) {
            return obj == this;
        }
        Figur andereFigur = (Figur) obj;
        return Objects.equals(typ, andereFigur.typ) && Objects.equals(farbe, andereFigur.farbe);
    }

    public int hashCode() {
         return Objects.hash(typ, farbe);
    }

    public String toString() {
        return "Figur [typ=" + String.valueOf(typ) + ", farbe=" + String.valueOf(farbe) + "]";
    }
}

Nachtrag, nur zur Klarstellung: "unveränderliche Daten" soll heißen, dass es nicht möglich ist, die Attributwerte von Objekten dieser Klasse zu ändern. Wenn die Attribute Objekte referenziert werden, die ihrerseits verändert werden können, ist das natürlich nach wie vor möglich.

 

[Gelöschtes Mitglied 65838]

"unveränderliche Daten"

sind aber trotzdem nicht immutable.. innere werte kann man in records immer noch ändern

 

[mihe7]

sind aber trotzdem nicht immutable.. innere werte kann man in records immer noch ändern

Das habe ich am Ende extra noch dazugeschrieben