Simple User Interface Frage

[Samuel]

Die Frage ist zwar so simpel, aber ich komme auf keine zufriedenstellende Lösung.

Ein Teil des Problems ist die Frage, ob ich bei OOP mit einer UIF Klasse die UIF Klasse als static oder nicht definiere.
Braucht man von der UIF eine Instanz?
Und eine ähliche Frage im selben bezug, wenn ich eine Klasse UIF habe und zwei Klassen wie Controller und Spieler habe, kann dann Spieler ebenfalls die UIF benutzen?
Es geht nämlich darum, dass der Controller die UIF ja kennt, aber wie soll die Spieler Klasse die UIF kennen?
Andererseits gibt da noch die Frage, wenn ich die UIF durch eine GUI ersetzte, so muss ich doch im Falle von static, den ganzen Code umschreiben, oder? Überall wo ich die statics benutze, muss ich ja UIF.methode(); in den Klassen suchen und durch GUI.methode(); ersetzen.
Wie handhabt man denn sowas?

Also es gibt erstmal eine UIF, die wird später durch GUI ersetzt, aber ich möchtre nicht bild drauf los programmieren, während ich diese großen Lücken da oben in meinen Gedanken habe.

Danke

 

[Beni]

Tja, die Frage ist leicht zu beantworten: wenn du sie static definierst, ists kein OOP mehr :wink:

Du kannst Objekte per Referenz übergeben, hier hat es ein paar Beispiele.

 

[Samuel]

Ok, dann nicht static, aber das Szenario sieht grob umrissen so aus:
Es gibt einen Controller, einen Spieler und eine UIF.
Controller kennt Menge von Spielern und UIF.
Controller ist ein Spiel, in einer Schleife werden dann abwechselnd der Reihe nach die Spieler durch gegangen, grob:

Controller{
 UIF ui = new UIF();
 Spieler[] spieler = ....;
 public void function ablauf(){

 schleife(){
   //spieler 1
  position = ui.SpielerGibPosition(); 
  // tu was mit Spieler 1 Position
  //Spieler2
  position = ui.SpielerGibPosition();
  //tu was mit Spieler 2 position
 }

 }

}

Die Klasse Spieler enthält Namen usw.

Aber ist das da oben im Sinne vom Modellieren der Wirklichkeit?

Müsste das nicht eher so aussehen, dass der Controller den Spieler bittet, den Zug zu geben?

also sowas

Controller{
 UIF ui = new UIF();
 Spieler[] spieler = ....;
 public void function ablauf(){

 schleife(){
   //spieler 1
  position = Spieler[1].gibPosition(); 
  // tu was mit Spieler 1 Position
  //Spieler2
  position = Spieler[2]gibPosition();
  //tu was mit Spieler 2 position
 }

 }

}

Man bittet also den jeweiligen Spieler, den Zug zu geben, wobei dann der jeweilige Spieler eigentlich die ui mit SpielerGibPosition(); aufruft, es geht ja nicht, dass Spieler IO macht.
Es ist zwar natürlicher modelliert, aber was hiervon ist dem sinngemäßen OOP Gedanken näher?

Wir hatten bis jetzt immer nur abstrakte Controler - Spieler/User Verhältnisse, dort hatte immer Spieler die Aktion, wie gibZug usw, aber mit der UIF bin ich nun verwirrt

 

[Beni]

Das Model (hier die Spieler) sollten in einem engen MVC garnicht wissen, dass es da eine GUI gibt. Von dem her, würde ich den Controller die Abfrage machen lassen. Speichern würde ich die Position aber dann in den Spielern, da das ein Attribut der Spieler ist.

 

[Samuel]

Was bedeutet MVC?
Und es geht um eine Modellierung von dem Spiel Risiko.
Spieler ist eigentlicb nur dazu da um eine Referenz der Bereiche zu sein, die ihm gehören.
Also sollte niemand, ausser dem Controller sich um UIF kümmern?

 

[bygones]

MVC = Model - View - Controller. Ein Design Pattern für die logische Trennung der 3 Ebenen... siehe FAQ Beitrag "Design Patterns"

 

[Samuel]

Ich Idiot, natürlich
Hab sogar n ganzes Buch über Entiwcklungsmuster.

Aber was mir auch beim MVC noch nicht vollständig klar ist, ist das sehr modulare Modell, was bei uns zufällig rausgekommen ist.
Wir planen oder haben zu planen das Spiel Risiko, man muss halt Länder erobern, nun hat uns unser Entwurf zufällig die Möglichkeit gegeben Länder beliebig auszutauschen, also mit wenig Aufwand Risiko für Deutschland, Risiko für Berlin usw zu machen, wir haben die Unterländer als Provinzen definiert, diese haben eine Provinzmenge, welche ihre Nachbarn definiert, die gesammte Provinzen sind in der abstrakten Klasse Spielbrett, von dieser muss man erben und Spielbretter nach Wahl erstellen, SpielbrettDeutschland, SpielbrettWelt usw, dort werden die Provinzen halt mit Namen usw gefüttert.
Das funktioniert auch soweit ganz angenehm, aber wenn man Modell vom View trennt, was ja logisch ist, woher weiß dann die GUI, wie sich das spezielle SpielbrettX zu zeichnen hat?
Wir haben zwar ne Implementation der Provinzen, so dass diese ihre Nachbarn kennen, aber die GUI muss ja auch wissen, wie die Grenzen der Länder usw aussehen.
Mir fallen nur zwei Dinge ein, entweder SpielbrettX muss eine Methode zeichenDich haben, wobei MVC wieder hinfällig wäre, oder es muss noch extra für das jeweilige GUI/UIF eine implementierung der Karte als User Interface geben.
Denn bei einer Konsolenausgabe muss die Karte freilich ein wenig simpler aussehen, als bei einer GUI.
Natürlich wäre es ziemlich unpraktisch, beim wechseln des Spielbretts die GUI auch vollständig tauschen zu müssen, weil die GUI/UIF ja nicht nur vollständig aus der Kartenimplementation besteht.
Wenn ich SpielbrettBerlin durch SpielbrettDeutschland tausche bleibt die GUI im Bezug auf Eingaben und Menüs ja gleich, nur eben die Kartendarstellung nicht

 

[dbase]

Hallo,

wenn ich dich richtig verstanden habe, und dass muss jetzt nicht unbedingt sein...da ich schon sehr lange wach bin:-D...könntest du dir einfach mal das Singleton pattern ansehen...das sieht im Groben so aus...


1. Statische Variable vom Typ deiner Klasse definieren

public static MeineKlasse instance;

nun eine Methdode schreiben, die dir meinetwegen die GUI baut und das Objekt der Klasse liefert.

public static MeineKlasse getInstance() {

if(MeineKlasse.instance==null) {
//Baue mir meine GUI auf...
}
return MeineKlasse.instance;
}

Diese Klasse könnte eine Methode besitzen wie bspw.

public int getWasAuchImmer() {

return wasAuchImmer;

}

Somit kannst du von jeder anderen Klasse auf das Objekt zugreifen...

//In irgendeiner Klasse

MeineKlasse.getInstance().getWasAuchImmer();

Wenn ich dich falsch verstanden habe, dann einfach ignorieren^^

Gruß dbase[/code]

 

[Samuel]

Muss gleich weg und mir fällt nich ne Frage ein (gucke mir den Singleton post später genauer an)

Ist ein folgendes Szenario legitim?
Ich habe eine temporäre Klasse Armee, diese wird nur erzeugt, wenn man von einem Land ins andere will.
Aber kann die GUI eine Armee zurück liefern? Also darf die GUI spielspezifisch arbeiten?
Gemeint ist, Controller fragt GUI, von wo nach wo sollen wieviele Armeen bewegt werden.
User tippt dann a,b 20 in GUI ein, kann dann die GUI ein Armee Objekt zurückliefert, aus den Daten a,b, 20?
Oder soll eine GUI nur ints oder Strings liefern?

 

[Samuel]

Moment mal, hilft mir hier überhaupt MVC weiter?
Der Controller bestimmt doch die Möglichkeiten, wie Benutzerschnittstellen auf Benutzereingaben reagieren, aber wo ist dann die GUI? Die GUI ist doch in meinem Fall die Benutzerschnittstelle, als auch das View Objekt

 

[Beni]

View: die GUI
Model: die Daten
Controller: Das Ding das zwischen Model und View verhandelt. Der Controller kann manchmal mit der View "verschmelzen", das ist nicht sooooo schlimm. Schlimmer ist, wenn Model und View verschmelzen, dann gibts echten Codesalat.

 

[Samuel]

Achso!
Verstehe, allerdings frage ich mich, wer soll denn in meinem Fall nun wissen, wie mein SpielbrettX aussieht?
Muss die GUI noch eine GUI Version des SpielbrettX kennen? Welche dann sich selbst zeichnet?

 

[bygones]

ich bin jedenfalls verwirrt... ist das Spielbrett nicht die GUI ?!

 

[Samuel]

Hehe, nein, Spielbrett ist Abstrakt, die konkreten Spielbretter wie SpielbrettDeutschland usw implementieren die Menge der Subländer (habs mal Provinzen genannt) in der Form, dass man halt jeder Provinz einen Namen und eine Menge an Nachbarprofinzen gibt.
Das ist halt relevant, damit man später prüfen kann, ob man von Provinz A nach Provinz B kommt, dass ist nur die Logikschicht des Spiels.
SpielbrettX enthält bis jetzt nichts davon, wie das Spielbrett aussehen kann, damit ist es doch ein Teil vom Modell, oder? Somit dürfte es ja nichts mit der graphischen Darstellung zutun haben, würde das Teil ebenfalls die Informationen für das graphische beinhalten, müsste ich ja das Spielfeld komplett überarbeiten, wenn ich anstatt einer GUI doch lieber eine UIF als Konsolentextadventure haben möchte

Irgendwie ist da n Wurm drin, weil ich nicht weiß , wie ich die austauschbaren Spielbretter ebenfalls mit einer GUI kombiniere ohne alles zu vermischen