[Cojote]

Hallo,

zunächst mal sorry für den bescheuerten Titel, leider ist mir kein passenderer eingefallen.

Es geht um folgendes:
Fürs Studium soll eine Java Applikation für das Spiel 4 gewinnt geschrieben werden. Es soll Mensch gegen Mensch, PC gegen PC und Mensch gegen PC spielbar sein. Soweit kein Problem.

Diese Applikation soll jedoch über mind. 2 versch. Benutzerschnittstellen spielbar sein: Einmal rein textuell über Kommandozeile aber auf Wunsch auch über mehrere verschiedene Swing Oberflächen.
Ich habe zwar gute Java allgemein Kenntnisse habe aber leider noch nicht viel, bzw gar nicht mit grafischen Oberflächen in größeren Projekten gearbeitet. Hier fehlt mir vor allem Wissen über Kommunikation von der Oberfläche mit der Logik. Viele Mitstudenten haben das Problem bereits gelöst bei ihnen ist jedoch immer die Benutzeroberfläche das Herzstück und übernimmt sämtliche Aufgaben. Daraus resultiert dass sie mit jeder Einführung einer neuen Oberfläche auch ein Großteil der Logik nochmals implementieren. Diese Implementation könnte ich wohl auch umsetzen, jedoch halte ich sie für sehr unsauber und problematisch.

Die zentrale Frage die sich stellt ist:
Wie trenne bzw verberge ich die gesamte Programmlogik hinter den Benutzeroberlächen-Klassen?

Prinzipiell habe ich mir den Aufbau in etwa so vorgestellt:
Es existiert ein Controller-Klasse (sie und nicht die grafische Oberfläche ist das Herz der Anwendung). Sie initialisiert eine Oberflächenklasse (eine der Swing-Klassen oder die Text-Klasse), weist sie an und nimmt Benutzereingaben entgegen. Die Benutzerschnittstellen-Klassen implementieren alle das gleiche Interface, sodass jede Oberfläche stellvertretend für das Interface im Controller verwendet werden kann.

Leider habe ich keinen blaßen Schimmer wie ich Eingaben aus einer grafischen Oberfläche an den Controller zurückgebe. Ich kann in der Oberflächenklasse ja kaum mit return arbeiten oder? Wenn ein Stein in ein Feld gesetzt wird soll das grafische Fenster ja auch nicht geschlossen sondern lediglich blockiert werden bis die Logik den Spielzug ausgeführt hat. Threads sollten nach Möglichkeit nicht verwendet werden, sind aber auch nicht ausdrücklich verboten.

Ich wäre sehr dankbar wenn mir jemand einen Link zu einem Projekt oder Links zu Materialien schicken könnte, damit ich mir ansehen kann wie soetwas sauber umgesetzt werden kann.

Tausend Dank für eure Hilfe
Gruß
Christian

[Ben]

Hmmm,
was meinst du denn hiermit:

Ich kann in der Oberflächenklasse ja kaum mit return arbeiten oder?

Du kannst die Eingabe ja innerhalb der entsprechenden Klasse bearbeiten und dann an den Controller übergeben.
Letztlich ist es ja dann egal, wo die Informationen herkommen. Hauptsache sie gelangen in den Controller, der diese dann weiterverarbeitet.

Kurz: Ich hab nicht so ganz verstanden, wo dein Problem liegt *g* .

Grüße Ben.

[Cojote]

Vielen Dank für die schnelle Antwort.

Da hast du natürlich recht.
Ich mach mal ein kleines Beispiel zum starten des Spiels. Zunächst rufe ich im Controller die Methode showStartScreen() der Benutzeroberfläche auf. Dadurch kommt nun die Oberflächen-Klasse zum Zug
In dieser Methode initialisiert die Benutzeroberflächen-Klasse (hier eine Swing) nun ein grafisches Fenster mit allen notwendigen Angaben. Es existiert ein OK Knopf. Beim betätigen dieses Knopfs soll der Controller wieder zum Zug kommen und angewiesen werden die Daten aus der Benutzeroberflächen Klasse abzuholen.
Der Controller validiert die Eingaben. Sind sie ok bekommt die Oberfläche den Befehl das Fenster zu schließen.
Meine Frage ist nun: Wie erkennt der Controller dass etwas eingegeben wurde und kann genau an dem Punkt an dem er die Oberflächen-Klasse angewiesen hat wieder aufsetzen?
Ich habe es zunächst mit einem Observer versucht aber da kann ich ja auch nicht direkt wieder an dem Punkt aufsetzen.

Das mit dem return habe ich geschrieben da ich befürchte dass so ja die Ausführung der Oberflächen-Klasse direkt abgebrochen wird und somit auch das Fenster sofort verschwindet. Ist das inkorrekt?

Was ich möchte ist eine Art VC-Pattern wie ich es schon aus PHP kenne.


Oder mal so gefragt:
Ist es überhaupt möglich was ich vorhabe oder ist das Wolken-Kuckucksheim?

[Ben]

Zitat von Cojote

Der Controller validiert die Eingaben. Sind sie ok bekommt die Oberfläche den Befehl das Fenster zu schließen.

Versteh ich nicht. Warum wird das Fenster denn geschlossen?

Zitat von Cojote

Meine Frage ist nun: Wie erkennt der Controller dass etwas eingegeben wurde und kann genau an dem Punkt an dem er die Oberflächen-Klasse angewiesen hat wieder aufsetzen?

Hm. Was meinst du denn damit?
Hab ich nicht verstanden .

Zitat von Cojote

Ich habe es zunächst mit einem Observer versucht aber da kann ich ja auch nicht direkt wieder an dem Punkt aufsetzen.

Wäre auch mein erster Ansatz gewesen.

Zitat von Cojote

Was ich möchte ist eine Art VC-Pattern

Das Model-View-Controller-Pattern ist ja nicht strikt definiert. Demnach finde ich "eine Art VC-Pattern" passend *g* .

Grüße Ben.

[franz77]

Hallo Cojote!

Zunächst rufe ich im Controller die Methode showStartScreen() der Benutzeroberfläche auf. Dadurch kommt nun die Oberflächen-Klasse zum Zug

Das muss nicht so sein, bzw. glaube ich ist das Dein Hauptprobleme, natürlich muss die Zusammenarbeit (Kolaboration) der Komponenten Model, View und Controller irgendwie ans laufen gebracht werden, wenn das eine eigene Komponente tut, dann ist das kein Beinbruch.

...angewiesen werden die Daten aus der Benutzeroberflächen Klasse abzuholen

??? Das sollte bei einem MVC Muster wie es bei Swing eingesetzt werden kann anders sein. Eigentlich soll die Oberfläche die Daten nur darstellen, warum Du dort was abholen willst verstehe ich nicht. (Achtung! Ein MVC Muster, dass im Bereich Web Entwicklung eingesetzt wird unterscheidet sich von einem MVC Muster für Dektop Anwendungen und zwar weil Web Anwendungen, zumindest nativ nur ein Pull-Kommunikationsmodell anwenden können. Das ist bei Dektopanwendungen anders (MVC vs. MVC2). Siehe Observer --> Push Kommunikationsmodell)

Wie erkennt der Controller dass etwas eingegeben wurde und kann genau an dem Punkt an dem er die Oberflächen-Klasse angewiesen hat wieder aufsetzen?

Der Controller teilt dem Modell mit, das es geändert wurde. Das Modell informiert seine Clienten (Views) darüber. Diese Zeichnen sich dann neu. Um den Controller zu informieren würde ich Events einsetzen.

Ich hoffe ich konnte ein wenig helfen.
Gruss!
Franz