Erste Schritte Grundsätzlicher Aufbau

[krgewb]

Was ist eigentlich "Titel"?

 

[Reggie()]

das ist eine Kasrtenart und war ehemals eine Klasse

 

[Reggie()]

Frage zur Rundensteuerung:
ich dachte mir ich "mische" zu Beginn einer Partie Collection.shuffle(mitspieler) die Spieler durch und lasse dann reihum die Spieler (und Computer) an die Reihe kommen, indem ich über eine variable der Hauptklasse überwache/steuere, wer gerade dran ist public byte aktiverSpieler
Die Frage ist nun: Kann man das so machen und kann ich in allen Methoden auf diesen Wert zugreifen? zB über partie.activerSpieler

 

[krgewb]

Wieso wieder byte? Du hast es doch inzwischen zu int geändert.
Wenn es public ist, kannst du es überall ansprechen. Wenn du aber die Zeile
partie.aktiverSpieler
auch in einer anderen Klasse ausführen willst dann musst du es übergeben. Also als Parameter: Piratenspiel partie

PS: Später wirst du lernen, dass public nicht gut ist. Stattdessen werden solche Attribute auf private gesetzt und es werden Getter und Setter programmiert.

 

[Reggie()]

so, nun wieder eine Frage, die genau zum Thema gehört.
ich habe meinen gesamten Code dahingehend geändert, dass ich kein Objekt der Hauptklasse (die mit der main) erstelle. ich fand das war ein enorm großer Aufwand die Klassenvariable vor JEDEN Aufruf zu setzen. Stattdessen habe ich in der Hauptklasse alle Methoden static gemacht.
Jetzt die Frage: Widerspricht das dem Grundgedanken der OOP? Ich dachte mir, welchen Sinn macht es alles auf dieses eine Objekt zu beziehen, wenn es immer nur (in meinem Fall) EIN Objekt geben wird?
Oder habe ich die falsche Klasse als Hauptklasse gewählt? In Beispielen sehen ich oft, dass die Hauptklasse die der gui ist.

 

[krgewb]

Es gibt das Singleton Pattern https://de.wikipedia.org/wiki/Singleton_(Entwurfsmuster)

 

[mrBrown]

Widerspricht das dem Grundgedanken der OOP?

Ja, widerspricht dem

Ich dachte mir, welchen Sinn macht es alles auf dieses eine Objekt zu beziehen, wenn es immer nur (in meinem Fall) EIN Objekt geben wird?

Das wird kaum bei einer Klasse bleiben, spätestens beim nächsten Programm hast du dann mehr als eine

Oder habe ich die falsche Klasse als Hauptklasse gewählt? In Beispielen sehen ich oft, dass die Hauptklasse die der gui ist.

MMn ja, ich würde Main und GUI getrennt halten, und die Main nur die GUI initialisieren lassen. Die meisten Tutorials sind dafür aber zu kurz.

Bei jedem größeren Projekte führt static unweigerlich zu Problemen. Die meisten fangen genauso an, und müssen dann später alles über den Haufen werfen.
Generell ist es ratsam, alle Methoden die irgendwelche Variablen verändern, NICHT static zu machen.

Es gibt das Singleton Pattern https://de.wikipedia.org/wiki/Singleton_(Entwurfsmuster)

Und das sollte man weder verwenden, noch hat es hiermit irgendwas zu tun. (Oder läuft hier ein verstecktes Bullshit-Bingo-Spiel?)

 

[Reggie()]

sobald mein Programm (MauMau-Kartenspiel ohne GUI, also Textbasiert) läuft, werde ich es mal posten (in der code-Sektion?). Sobald der code "optimiert" ist, baue ich eine GUI drumherum.
Dieses Programm soll mir helfen Java in der praktischen Anwendung zu lernen.

 

[Reggie()]

In einem anderen Thread habe ich von EnumMap erfahren. Wäre das nicht auch sinnvoll für ein Kartenspiel?

 

[mrBrown]

EnumMap mMn nein, aber enums an sich können sinnvoll sein, zB als Kartentyp

 

[krgewb]

@Reggie() Weißt du wie Enum geht?

 

[Reggie()]

ich habe mich jetzt die letzten 2 Tage in das Thema Enum eingelesen und ich denke ich verstehe den grundsätzlichen AUfbau und Funktionsweise, aber mir ist nicht so ganz klar, wofür das nützlich/wichtig sein soll. Es wirkt so ein bisschen wie ein 2-Dimensionales Array mit Konstanten-Variablen.
Kann mir jemand mit kurzen Worten erklären, wofür man unbedingt Enums braucht bzw. für welches "Problem" sie die einzige (sinnvolle) Lösung sind? Die vielen Beispiele, die ich zu Enum gelesen habe waren alle Bullshit.

 

[mrBrown]

Sie sind eig genau das: Konstanten.

Du hast zB in deinem Kartenspiel unterschiedliche Kartentypen, aktuell sind dies ja Strings, ich kann also alle richtigen Typen nehmen, allerdings auch "Blablub" und "Ananassaft", was offensichtlich keine Kartentypen sind. Außerdem bleiben es halt Strings, und den Substring eines Kartentyps oder dessen Länge braucht man ja kaum.

Stattdessen kann man einfach einen Enum nutzen.

enum Kartentyp {
PIK, KARO, KREUZ, HERZ
}

(Sind jetzt nicht deine )

Außerdem sind enums auch sortierest, in der Reihenfolge die du angibst und lassen sich mit == vergleichen.
Enums können zusätzlich noch Methoden haben, du kannst den Kartentypen also die Methoden geben, die sie brauchen

 

[Reggie()]

daher ja die obige Frage, ob sich Enums und EnumMaps sich für ein Kartenspiel eignen. Ich denke ja, aber ich muss erstmal damit rumexperimentieren.

 

[mrBrown]

Enums ja, für EnumMaps muss man aber etwas suchen, die sind halt spezieller

 

[Reggie()]

zum eigentlichen Thema "Grundsätzlicher Aufbau": Ich habe aktuell die gui als eigene Klasse definiert und lege im Konstruktor des Spiels ein Objekt der gui-Klasse an. Aber irgendwie habe ich Probleme auf Elemente der Gui später aus Methoden der Huaptklasse zuzugreifen. Wie löst man idR das mit der gui?

 

[mrBrown]

Indem die Hauptklasse nicht auf die GUI zugreift

Ansonsten der übliche Weg: Instanzvariable und public Methoden

 

[Reggie()]

könntest du das gob (ohne code) skizzieren?

 

[SeriousD0nkey]

ich habe mich jetzt die letzten 2 Tage in das Thema Enum eingelesen und ich denke ich verstehe den grundsätzlichen AUfbau und Funktionsweise, aber mir ist nicht so ganz klar, wofür das nützlich/wichtig sein soll.

Nur mal so zur Ergänzung:

Sie sind sehr nützlich, wenn du irgendwelche Werte darstellen willst wo du im ersten Moment Strings für verwenden würdest. Das hat unter anderem den Vorteil, dass du (und deine Kollegen) sich nicht vertippen können. Oder wenn sich der Key in der Konfiguratinsdatei mal ändern sollte, brauchst du nur den Key(als den String) im Enum anpassen, aber nicht überall dort wo der Key eingesetzt wird.
Ein Beispiel könnte so aussehen:

public enum ConfigKey {
  
    KEY1("key1"),
    KEY2("key2"),
    KEY3("key3");
  
    private String key;
  
    ConfigKey(String key) {
        this.key = key;
    }
  
    public String getKey() {
        return this.key;
    }
  
}

Bei einer Konfiguration mit Apache Configurations währe dann z.B. der Aufruf folgendermaßen:

String value = configuration.getString(ConfigKey.KEY1.getKey());

Hat zwar jetzt vielleicht nix direkt mit deinem Thema zu tun, aber nur mal so, wo Enums meiner Meinung nach nützlich sind.

 

[mrBrown]

Sie sind sehr nützlich, wenn du irgendwelche Werte darstellen willst wo du im ersten Moment Strings für verwenden würdest.

Nein, generell immer dann, wenn man Konstanten braucht, die nicht explizit ein anderer Datentyp sein müssen, Strings kann man genauso gut als Konstanten deklarieren, die lassen sich zB auch ziemlich gut mit dem Strategie-Pattern verbinden.

In deinem Beispiel gewinnt man durch enums nichts, nicht mal Typsicherheit. Da kann man besser ConfigKey.KEY1 als String deklarieren und den nutzen, dann spart man sich das getKey()

 

[krgewb]

Indem die Hauptklasse nicht auf die GUI zugreift

Ansonsten der übliche Weg: Instanzvariable und public Methoden

Getter und Setter?

enum Kartentyp {
PIK, KARO, KREUZ, HERZ
}

Eventuell muss er aber danach noch die Instanzvariable erstellen:

Kartentyp m_kartentyp;

(Sind jetzt nicht deine )

Also in seinem Fall Personenkarte und Titel ?

 

[Reggie()]

gibts denn kein einfaches Beispiel, bei dem die Verwendung von Enum unverzichtbar ist?

 

[mrBrown]

gibts denn kein einfaches Beispiel, bei dem die Verwendung von Enum unverzichtbar ist?

Es gibt nicht mal ein Beispiel wo Java unverzichtbar wäre

Unverzichtbar ist kaum etwas, es macht einiges nur deutlich leichter und angenehmer.

Getter und Setter?

= public Methoden (ich bin aber kein Fan von get/settern in Guis...)

Also in seinem Fall Personenkarte und Titel ?

Wenn es nur die beiden Typen gibt, ja.

 

[Reggie()]

lassen wir man die Enums beiseite. ich wollte etwas über einen sinnvollen Aufbau (Programmstruktur) wissen.
ich habe bisher folgenden Aufbau:
class Kartenspiel mit main: in dieser Klasse werden die Karten erstellt in ArrayList<Karte>), Spieler erstellt in ArrayList Spieler und mittels methoden Karten an die Spieler ausgeteilt und sonstige Programmlogic, die eigentlich fast nur den Weg der Karten von einer ArrayList zur anderer beschreibt. Ist die ArrayList eines Spieler leer, hat er gewonnen.
class Karte: Konstruktor
class Spieler: Konstruktor und methoden zu Aktionen des Spielers
class gui: Konstruktor erstellt den Spieltisch mit allen Bedienelementen, instanz wird im Konstruktor von Kartenspiel aufgerufen.

 

[mrBrown]

Klingt soweit sinnvoll

 

[krgewb]

Huhu Reggie. Wie sieht's aus?

 

[JStein52]

Das Zeug ist vom 29.3. ! Wir sind inzwischen 3 Monate später. Hast du mal geguckt wann der gute Reggie zuletzt hier war

 

[Reggie()]

hi Leute. Stimmt, ich war lange weg. Das hatte den Grund, dass ich Unity entdeckt habe. Da wird einem viel abgenommen und ich muss dafür auch "nur" C# lernen. Das ist wie Java light
Also danke für die bisherige Hilfe und machts gut.