OOP Überwachen, ob ein Objekt erzeugt wird

[Juergen-87]

Hallo,
ich bin an einer kleinen Spiel-Programmierung. Zuerst werden die Spieler geladen und dann wird mit der Methode los() die eigentliche Gui erzeugt. Auf der Gui wird dann per Button ein spiel-Objekt erzeugt. Und sobald das passiert ist, soll ein neues Fenster aufgehen, in dem das eigentliche Spiel gespielt wird. Jetzt weiß ich nicht genau, ob es da eine Art Listener gibt, der einspringt, sobald ein Objekt nicht mehr null ist???
Ist hab das erstmal so gelöst, dass ich nach erzeugen der Gui in der main() eine Schleife eingefügt habe, die nur dann verlassen wird, wenn das Objekt != null ist.
Gibt es da eine bessere Möglichkeit???
Mein Code an de Stelle:

public static void main(String[] args){
		spielerLaden();
		gui = new Gui();
		gui.los();
		while(spiel == null){
			System.out.println("");
		}
		System.out.println("funktioniert"); // nur testhalber, hier kommt dann der Fensterwechsel hin
	}

 

[Bug Fisher]

Hallo Jürgen87,

du hast richtig erkannt, dass so wie du das machst auf keinen Fall richtig und praktikabel sein kann.
Spinloops (oder busy waiting) sind -Gott sei Dank- nur auf Betriebssystemebene (und dort auch nur hier und da zu finden) notwendig und der einzige Weg.

Die Hälfte der Geschichte ist, dass Listener genau diesem Problem entgegenwirken; man nennt das inversion of control.

Für deinen Fall jedoch sieht die Sache anders und mithin viel einfacher aus:
Erzeuge dein Spiel-Objekt einfach in der main() oder aus Konstruktoren anderer Objekte.
Wenn du jetzt sagst, dass du das Spiel-Objekt erst nach Benutzen der gui (eben durch einen Klick) instanziieren kannst, weil dir sonst Parameter fehlen, dann lass den Spiel()-Konstruktor nur die Argumente verlangen, die du vorher schon weisst und erledige den Rest durch geeignete Setter.

Ausserdem: Erstelle besser alle Objekte im Konstruktor der Main-class und erzeuge in der main() nur ein Objekt davon. Es ist nicht OO, dass gui static ist, auch wenn du im Leben nur 1 Exemplar davon brauchst.

(Übrigens:
dein while(spiel == null), also das busy waiting, wird der main-Thread ausführen - somit kann es sogar, mehr oder weniger selten, dazu kommen, dass die Schleife durch den cache-mechanismus und die jit-hotspot-compilierung niemals beendet wird, da das Spielobjekt ja durch den gui-Thread (EDT) erstellt wird. Wenn dich das mehr interessiert, schau dir mal Erklärungen zum volatile-Schlüsselwort an.
)

 

[Juergen-87]

Danke für die schnelle Antwort.
Das letztere ist auch eingetreten Deshalb kam ich darauf, dass da irgendwas nicht stimmen kann.

Vielleicht habe ich auch im ganzen Programmaufbau etwas falsch gemacht.
Es läuft folgendermaßen ab.

Meine main() ist die Gui-Klasse. Die main() lädt dann als erstes über die Methode spielerLaden() die vorher gespeicherten Spieler und öffnet dann ein Fenster in dem ich einen Spieler auswählen kann und ein Level des Spiels auswähle. Dann drücke ich den Start-Button und danach soll ein Spiel im entsprechenden Level gestartet werden. Dazu übergebe ich dem Konstruktor der Klasse Spiel einen int-Wert der die Nummer des Levels (je nachdem welcher Radio-Button selektiert ist) darstellt.

public void actionPerformed(ActionEvent arg0) {
		if(eins.isSelected()){
			new Spiel(1);
		} else if(zwei.isSelected()){
			new Spiel(2);
		} else if(drei.isSelected()){
			new Spiel(3);
		} else if(vier.isSelected()){
			new Spiel(4);
		}
		startFrame.setVisible(false);
	}

Dabei wird gleich das Start-Fenster unsichtbar gesetzt und es soll das Spiel-Fenster geöffnet werden.
Das Spiel-Fenster und den ganzen Spielablauf wollte ich dann in der Spiel-Klasse programmieren (Habe ich aber noch nicht gemacht).
Und wenn das Spiel vorbei ist, sollte dann wieder in das Start-Fenster gewechselt werden.
Das sieht für mich (als Anfänger) jetzt vom Aufbau her erstmal ganz logisch aus. Aber vielleicht kann ich noch einen konkreten Tipp für mein Beispiel bekommen, ob besser etwas geändert werden soll.
Wenn noch ein paar Angaben zu meinem Programm fehlen, kann ich gerne noch was nachliefern.

 

[Bug Fisher]

Von deinen Informtionen her, würde ich dir Folgendes vorschlagen; ohne Anspruch auf Richtigkeit.
Erklärungen lasse ich einfach weg, weil du offenbar unerfahren mit dem Thema OO bist und das nach einiger Zeit für dich ganz selbstverständlich sein wird. (Eigentlich machst du es ja für Anfänger total richtig-schlüssig, da du erstmal rein prozederal-imperativ denkst)

public class Main() {
    private final Gui gui = new Gui();

    private Main() {}

    public static void main(final String... args) {
        new Main();
    }
}

public class Gui extends JFrame implements ActionListener {
    private final SpielerObjekt spieler;
    private Spiel spiel = new Spiel();

    public Gui() {
        spieler = spielerLaden();
        los();
    }

    private void los() {
    
    } 

    private SpielerObjekt spielerLaden() {

    }

    @Override
    public void actionPerformed(final ActionEvent e) {
        if(eins.isSelected()){
            spiel.setLevel(1);
        } else if(zwei.isSelected()){
            spiel.setLevel(2);
        } else if(drei.isSelected()){...}...

        spiel.show();
    }
}

Ich hoffe, ichg habe nichts übersehen.
Die Klasse Spiel bekommst du selbst hin.

 

[kaoZ]

public class Gui extends JFrame implements

aiaiaia.....

ich vermute mal du hast dich da an dem Code des TO's orientiert ?

falls dem so sein sollte ,

@ TO :

Bevor du anfängst Spiele zu entwickeln würde ich mich zumindest 'vernünftig' mit den Grundlagen der OOP auseinandersetzen, ein geringer Ansatz ist ja bereits zu erkennen.

es gibt in fast keinem Fall einen Grund JFrame zu erweitern, abgesehen davon wirst du spätestens ins stocken geraten wenn du beim Mulithreading angekommen bist, weil du feststellst das deine Gui sich einfach aufhängt wenn du komplexere Aktionen ausführst da diese dann ebenfalls im EDT stattfinden, und deine Gui blockieren.

Selbstverständlich kann man das ganze auch Prozedural angehen , aber es wäre sinnfrei eine OO Programmiersprache zu wählen und dann Prozedural zu programmieren, grade bei doch schon recht größeren Projekten wie einem Spiel und außerdem wird das auf dermaßen unübersichtlich das du irgendwann nicht mal mehr durch deinen eigenen Code durchblicken wirst.

Zusätzlich sollten immer nur Objekte selbst ihren zustand ändern können.

[EDIT]Wenn du Dinge , egal welcher Art überwachen möchtest , kann ich als Stichwort mal
Observer Pattern in den Raum werfen.


[/EDIT]

 

[Juergen-87]

Vielen Dank für die guten Ideen. Da werde ich bestimmt einiges davon umsetzen können.

Grundsätzlich habe ich mich schon mit OOP befasst. Ich studiere Informatik im 1. Jahr und habe mir halt jetzt als Ferienprojekt ein Spiel vorgenommen, um so einige Sachen auszuprobieren und zu testen. Dabei geht es auch nicht um eigene Kreationen, sondern ich habe mir ein (analoges ) Strategie-Kartenspiel genommen, das solitär gespielt wird. Also hier müssen keine Mehrspieler-Sachen umgesetzt werden und es gibt auch keine KI im Hintergrund, die das Spiel steuert. Das passiert dann wirklich mehr oder weniger prozedural in einer Schleife oder so. Das hab ich noch nicht so genau durchgeplant.

Aber zum Thema OOP gibt es dadrin mehrere Kartentypen, verschiedene Kartenstapel und etliche Sonderfunktionen, die auch teilweise voneinander erben und hierarchisch aufgebaut sind.
Das Problem liegt ja eher darin, den Programmstart und die Gui richtig hinzubekommen. Also in welcher Klasse liegt die Gui und in welcher wird dann das eigentliche Spiel durchgeführt.

Dafür fand ich die Idee von Bug Fisher ganz gut. Allerdings hab ich die ActionListener immer in extra Klassen geschrieben, weil ich z.B. mehrere Buttons und ComboBoxen auf der Gui habe, die jeweils einen extra ActionListener haben. Und ich bin nicht ganz sicher, warum ich JFrame erweitert muss???


@ kaoZ: Ich werde es jetzt vielleicht für das Projekt nicht brauchen, aber könnte ich denn mit Observer Patterns auch überwachen, ob einer Variablen ein Objekt zugeordnet wird? Ich hatte das Thema nämlich auch schon im Netz gefunden, aber kein passendes Beispiel. Ich hatte gedacht, dass Observer eher die Vorgänger der Listener sind und dass ich dann mit den Listenern auch alles machen könnte.

 

[Bug Fisher]

es gibt in fast keinem Fall einen Grund JFrame zu erweitern

Finde ich nicht. Meiner Meinung nach ist es näher am Modell der Objekt-Orientierung alle setter im Konstruktor der erweiternden Klasse aufzurufen, als irgendwo anders a là

final JFrame f = new JFrame();
f.setXXX();
f.add(...);
....

Also ich gebe dir in zwei Punkten recht:

1.) Da man prinzipiell als Klient an jeder beliebigen Stelle sowas wie

JFrame f = new Gui();

schreiben könnte, macht man eigentlich ein Implementierungsdetail öffentlich, was man nach OO ja nicht tun sollte. (Das gleiche trifft für implements ActionListener zu)

ActionListener al = new Gui();

Hier wäre private Vererbung, wie es in C++ möglich ist, angebracht, da hast du recht. Gibt es in Java aber nicht. Ist IMHO aber nicht ganz so schlimm, da man zwar NEUE Exemplare von aussen beliebig erzeugen könnte, das eigene aber trotzdem nicht kompromittieren kann (richtige Kapselung vorausgesetzt)

2.) Man kann natürlich auch zum Factory Pattern greifen um 1) zu umgehen. Soetwas wie

private static JFrame createGui()

würde trotz der Schwäche von Java gegenüber C++ das Problem von 1) umgehen. Stimmt.
Zumindest ich finde aber, dass das Argument oben gegen 1) ausreicht, um auch 2) nicht zu nutzen.
Ich persönlich nutze das Factory Pattern schon, aber nur wenn potentiell auch viele Exemplare, deren (komplexere) Konfiguration versteckt werden soll, angefordert werden. Das trifft auf ein HauptFenster, das ein JFrame ist, nicht zu.
Bei Dialogen ist das was anderes, das macht die Java-Bibliothek ja auch so vor. JOptionPane.show...Dialog() mit verschiedenen Überladungen ist ja ne Factory.

 

[stg]

Finde ich nicht. Meiner Meinung nach ist es näher am Modell der Objekt-Orientierung alle setter im Konstruktor der erweiternden Klasse aufzurufen, als irgendwo anders

public class MaxMueller extends Person {
    public MaxMueller() {
        this.setName("Max Müller");
    }
}

So in etwa?

 

[Bug Fisher]

public class MaxMueller extends Person {
    public MaxMueller() {
        this.setName("Max Müller");
    }
}

Das wäre natürlich grober Unfug, aber ich fasse deine Antwort als Provokation auf, und gehe vor diesem Hintergrund davon aus, dass du auch eher kaoZ's Meinung bist...

Hmm, ich sollte also nicht von JFrame erben, wenn es nicht wirklich um Funktionalität oder Member erweitert wird, weil es nicht erweitert wird ?
Wörter auf die Goldwaage: Bei Vererbung herrscht eine "ist-ein" Beziehung, die ist auch gegeben, wenn ich nichts (nichtprivates) hinzufüge.
Im Sinne der Wartbarkeit und der Trennung von Zuständigkeiten macht es IMHO aber doch Sinn, von JFrame zu erben und zB nur eine private void setupUI() hizuzunehhmen. BTW: wieso gibt es dann in der C++Welt den Ausdruck der ImplementierungsVERERBUNG, wenn eben nichts öffentliches hinzukommt ?
Ist ein JFrame nicht mehr als ein JFrame, wenn es gekapselt das gesamte Layout managt ?

Also ich will bestimmt nicht streiten, aber ich bleibe bei meiner Meinung.

 

[kaoZ]

Nach Konvention soll man eben aber auch eine Klasse nur erweitern wenn man ihr Funktionalität hinzufügt , da sich hier aber das ganze nicht im JFrame sondern in einem Container innerhalb des Frames abspiel und dies im Normalfall ein JPanel ist, frage ich mich was gegen folgenden Ansatz
spricht :

public class Gui{

	public static void main(String[] args){
		JFrame f = new JFrame("GameTest");
		f.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
		f.setContentPane(new GamePanel());
		f.setResizable(false);
		f.pack();
		f.setLocationRelativeTo(null);
		f.setVisible(true);
	}
}

die Gui stellt einfach nur das Fenster und kapselt die Funktionalität des "Rahmens" welcher als Content eben den GamePanel beinhaltet.

import game.gamestate.GameStateManager;
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;
import java.awt.image.BufferedImage;
import javax.swing.JPanel;


@SuppressWarnings("serial")
public class GamePanel extends JPanel{

	// dimensions
	public final static int WIDTH	= 320;
	public final static int HEIGHT	= 240;
	public final static int SCALE	= 2;
	
	// image
	private BufferedImage image;
	
	// gameloop
	private GameLoop loop;
	
	// gamestatemanager
	private GameStateManager gsm;
	
	public GamePanel(){
		setPreferredSize(new Dimension(WIDTH * SCALE, HEIGHT * SCALE));
		setFocusable(true);
		requestFocus();
	}

	
	public void init(){
		loop.start();
		image = new BufferedImage(WIDTH, HEIGHT, BufferedImage.TYPE_INT_RGB);
		gsm = new GameStateManager();
	}
	public void update(){
		gsm.update();
	}
	public void render(){
		Graphics g = image.getGraphics();
		
		if(g != null){
			gsm.draw(g);
		}
	}
	public void draw(){
		Graphics g = getGraphics();
		
		if(g != null) {
			g.drawImage(image, 0, 0, WIDTH * SCALE, HEIGHT * SCALE, null);
		}
		else{
			System.exit(0);
		}
	}
	
	@Override
	public void addNotify(){
		super.addNotify();
		addKeyListener(new GameListener());
		loop = new GameLoop(this);
	}
	
	class GameListener implements KeyListener{

		@Override
		public void keyTyped(KeyEvent e){}

		@Override
		public void keyPressed(KeyEvent e){
			gsm.keyPressed(e.getKeyCode());
		}

		@Override
		public void keyReleased(KeyEvent e){
			gsm.keyReleased(e.getKeyCode());
		}
	}
}

Also alleine von der Kapselung her finde ich den Ansatz einfach Sauberer, muss natürlich letzten endes jeder selber wissen

Das auslagern des GameThreads und des dazugehörenden loops scheint anfangs etwas verwirrend, aber ich hielt es für sauberer da das runnable ja letzen endes nichts im GamePanel zu suchen hat.