Implementiere das Player Objekt, welches eine einzigartige Bezeichnung(UID), Nicknamen der Spieler beinhaltet und Methoden beinhaltet für die spielerbezogenen Daten

[Sen66]

Referenz User-Stories #12 #14 #15 #19 #33

[alablz]

Präzisierung der Spielerbezogenen Daten wäre sinnvoll oder ? (z.B. Spielername) :)

[Sen66]

Präzisierung der Spielerbezogenen Daten wäre sinnvoll oder ? (z.B. Spielername) :)

Ja! Gutes Beispiel, ein Player Objekt wird mit Sicherheit eine große Bedeutung spielen, vor allem wenn es mehr in Richtung GUI geht und weitere Features hinzukommen. Ein Spielernamen in der CommandLine Version stelle ich mir auch gut vor. Wenn du magst, kannst du ja die Tasks/Tests hierfür implementieren?

[alablz]

Sollen wir die spielbezogenen Daten aus der Playerklasse extrahieren und in eine separate Klasse packen, die die Playerklasse dann als Feld erhält ? Ein möglicher Task hierzu :
"Implementiere die Klasse Playerdata die spielerbezogene Daten enthält unabhängig von der Oberfläche ( GUI und Konsole )"

[Sen66]

Sollen wir die spielbezogenen Daten aus der Playerklasse extrahieren und in eine separate Klasse packen, die die Playerklasse dann als Feld erhält ? Ein möglicher Task hierzu :
"Implementiere die Klasse Playerdata die spielerbezogene Daten enthält unabhängig von der Oberfläche ( GUI und Konsole )"

Erachte ich für den Anfang als nicht vonnöten. Das Spieler Objekt hat bis jetzt wahrscheinlich eine interne ID, eine UID (vielleicht sogar ID=UID), einen Namen. Ich finde eine Aufspaltung hierbei ist erst als sinnig, wenn es wirklich viele Daten gibt, auch eher noch andere Daten als Spielerbezogene sodass es so aussehen würde:

• Player
  • PlayerData
    • ID
    • UID
    • Name
  • UnknownData
    • Unknown Data 1
    • Unknown Data 2

Ich hoffe man versteht meine Abstrahierung, es ist aber nur meine persönliche Meinung

[alablz]

Dein Vorschlag ist in Ordnung "Playerdata" aus Player noch nicht zu extrahieren.