Konstruktoren

[johannesK]

In einer Übungsaufgabe sollen verschiedene Varianten von Minesweeper implementiert werden. Ich habe also eine Oberklasse MinesweeperGame und verschiedene Unterklassen (MinesweeperGameOrig, MinesweeperGameDiag, ..... ). In der Benutzerschnittstelle soll nun zu spielbeginn entschieden werden können welche variante man spielen möchte. Ich habe versucht das so zu lösen :

....
int mode;
// mode wird eingelesen über benutzerschnittstelle ...
  
    if (mode == 1) {
        MinesweeperGameOrig msg = new MinesweeperGameOrig(10,10,10,10);
    }
    if (mode == 2) {
        MinesweeperGameDiag msg = new MinesweeperGameDiag(10,10,10,10);
    }
    if (mode ==3) {
        MinesweeperGameOrtho msg = new MinesweeperGameOrtho(10,10,10,10);
    }
    ...
    ...

msg.open(3,3);
msg.mark(4,7);

Die verschiedenen varianten sollen alle den gleichen namen haben, damit ich die funktionen des spiels (spielfeld öffnen, fahne setzen, .... ) nicht für alle varianten explizit angeben muss (sondern eben nur msg.open() , msg.mark() ...) .

So wie es oben geschrieben steht kommt der Fehler: Cannot find Symbol: variable msg.

Ich habe es auch schon mit Hilfe einer switch anweisung versucht auch das hat leider nicht funktioniert.

Wie kann ich abhängig von der Eingabe des benutzers ein Objekt mit dem namen msg mit variierendem typ (spielvarianten) erzeugen???

Vielen Dank für die Hilfe

Johannes

 

[L-ectron-X]

msg

wird innerhalb einer if-Abfrage initialisiert. Außerhalb der Abfrage ist

msg

aber nicht mehr existent.
Du musst also die Variable oberhalb der if-Abfrage deklarieren.

MinesweeperGame msg = null;

 

[Landei]

Du kannst nur den Typen der Oberklasse angeben, ungefähr so:

MinesweeperGame msg = null;
switch (mode) {
  case 1: msg = new MinesweeperGameOrig(10,10,10,10); break;
  case 2: msg = new MinesweeperGameDiag(10,10,10,10); break;
  case 3: msg = new MinesweeperGameOrtho(10,10,10,10); break;
  default: throw new IllegalArgumentException("WTF?!?");
}
msg.open(3,3);
msg.mark(4,7);

Wenn deine Spielklassen weitgehend gleich sind, kannst du auch versuchen, nur das jeweils unterschiedliche Auswertungsverhalten u.s.w. zu kapseln, und die entsprechende "Strategie" deinem Spiel-Objekt zu übergeben:

Strategy strat = OrigStrategy(); //oder halt eine andere
MinesweeperGame msg = new MinesweeperGame(strat, 10, 10, 10, 10);

Das ist gewöhnlich die bessere Wahl, wenn die Unterschiede zwischen den Versionen nicht sehr groß sind.

 

[turtle]

Dafür gibt es in Java Interfaces!

Alle Methoden, die Du in den speziellen Unterklassen benötigst, kommen in ein Interface. Die Unterklassen implementieren dieses. Dann kannst Du Deinen Code so umschreiben:

int mode;
// mode wird eingelesen über benutzerschnittstelle ...
  MinesweeperGame msg = null; // Dies ist das Interface gegen das Du programmierst
    if (mode == 1) {
        msg = new MinesweeperGameOrig(10,10,10,10); 
    }
    if (mode == 2) {
        msg = new MinesweeperGameDiag(10,10,10,10); 
    }
    if (mode ==3) {
        msg = new MinesweeperGameOrtho(10,10,10,10);
    }
    ...
    ...
 
msg.open(3,3);
msg.mark(4,7);

Und Dein Interface sieht zum Beispiel so aus:

public interface MinesweeperGame {
   public void open(int a, int b);
   public void mark(int c, int d);
   ...

}

 

[johannesK]

Danke für die schnelle Antwort ... das funktioniert für die methoden der Oberklasse so auch (msg.mark() zB (eine Fahne setzten ist in allen Minesweeper varianten das gleiche)). Nur wenn ich jetzt ein feld öffnen will mit msg.open() (die methode ist in der unterklasse, da sich die varianten ja gerade im aufdecken der felder unterscheiden) dann geht das leider nicht {cannot find symbol: method open(int,int) }

Gibt es eine möglichkeit die methoden der unterklasse zu erreichen ??

Vielen Dank

Johannes

 

[turtle]

Wenn Du meinem Vorschlag gefolgt bist und eine Methode im Interface deklariert hast, MUSS diese in den implementierenden Klassen implementiert werden!. Dann kann es auch nicht zu Deinem Problem kommen.

Wenn das für eine konkrete Klasse keinen Sinn macht, kann eine leere Implementierung helfen, oder eine Runtime-Exception geworfen werden, oder, oder.

 

[Crian]

Wenn es Methoden gibt, die immer gleich wären, ist eine abstrakte Oberklasse aber sinnvoller als ein Interface.

 

[Landei]

Du kannst entweder ein Interface verwenden:

public interface MinesweeperGame {
    public void open();
}

public class MinesweeperGameOrig implements MinesweeperGame {
    public void open(){ ... }
}

Allerdings kannst du in einem Interface "gemeinsame" Methoden wie mark nicht definieren. Eine Lösungsmöglichkeit ist die Verwendung abstrakter Klassen:

public abstract class MinesweeperGame {
    public abstract void open(); //muss in Unterklasse implementiert werden
    public void mark(){ ... } //ganz normale Methodendefinition
}

public class MinesweeperGameOrig extends MinesweeperGame {
    public void open(){ ... }
}

 

[turtle]

Man kann auch eine (abstrakte) Adapter-Klasse bauen, die das Interface implementiert.

Unterklassen erben dann von der Adapter-Klasse und müssen nur die Methoden überschreiben wo das Verhalten anders ist als in der Adapterklasse.

Diese Entscheidung würde ich echt davon abhängig machen, wie viel Code in allen Klassen gleich ist.

Sorry, erstens bin ich ein Fan von Programmierung gegen Interfaces und wollte dem OP dies näherbringen (SCNR)

 

[Crian]

Ich bin auch für Programmieren gegen Schnittstellen. Dies sollte man aber nicht mit Interfaces gleich setzen. Wichtig ist doch dabei, dass man nicht gegen eine konkrete Klasse programmiert. Ob hinter dem verwendeten Typ ein Interface oder eine (ggf. sogar abstrakte) Oberklasse steckt, tut der Programmierung gegen Schnittstellen keinen Abbruch.

Aus "Entwurfsmuster von Kopf bis Fuß" (4. korrigierter Nachdruck 2008 S. 12)

"Auf eine Schnittstelle programmieren" heißt eigentlich "Auf einen Supertyp programmieren".

[...]

Mit dem deutschen Wort Schnittstelle verweisen wir auf das allgemeine Konzept Schnittstelle (die nach außen sichtbare Seite einer Komponente, über die die Interaktion mit der Komponente gesteuert wird) [...]

Man kann also auf eine Schnittstelle programmieren, ohne dazu tatsächlich ein Java-Interface verwenden zu müssen.

 

[turtle]

Ich glaube wir verstehen uns und ich glaube dem OP ist auch geholfen