Hallo,

ich bin zur Zeit daran, ein einfaches Kartenspiel zu erstellen ( Mau-Mau ) und wollte euch Kritiker mal Fragen, was ihr an der Klasse generell verbessern würdet.



Und um einen Kartenstapel zu erstellen ( noch keine Mischfunktion integriert)

die Klasse Karten repräsentiert genau eine Karte. Also benenne sie auch Singular.

Da Farbe und Wert einer Karte im Konstruktor vorgegeben werden, mach die entsprechenden Properties ReadOnly.

Eine Frage hätte ich am Rande noch. Ich bin gerade dabei, mein Projekt mehrspielerfähig zu machen und habe das Grundgerüst soweit fertig. Da den Spielern jedoch auch das Kartenblatt/einzelne Karten vom Server zugesendet werden sollen und der Befehl zum senden ...StreamWriter.WriteLine(Object) auf das Objekt nur die .ToString Methode anwendet, muss das irgendwie beim Client wieder zusammensetzen. Dachte mir, dass es durch die Implementierung der KartenKlasse in den Client und die Typenkonvertierung beim Client Ctype(StreamReader.ReadLine, Karte) ginge. Bevor ich einen auf den Deckel bekomme: Ja ich habe Option Strict on und habe alleine nur für den Versuch oben schon einen vom Compiler aufn Deckel bekommen

tja, eine Karte ist eben kein String, und kann man auch nicht draus machen.
Doch! kann man doch draus machen, nämlich mitte .ToString - Funktion.

Aber ein String ist keine Karte und kann man auch nicht draus machen, auch nicht mit CType(). Deshalb die Exception.

Du befindest dich hier im Bereich von Parsen und Formatieren - da habich für die Nachwelt philosophisches zu hinterlassen: Hex-Zahlen?

Nun hast du viele Möglichkeiten - zB Serialisierung ist ein Standard-Verfahren - informier dich über XmlSerializer - das wird meistens genommen - oder BinaryFormatter oder JsonSerializer.

Nun dann mach es so:
Gib den Karten einen Namen: "Kreuz7", "HerzBube", "KreuzPik". Ein aus Farbe und Wert zusammengesetzter String, den Du anders rum wieder zu seinem richtigen Wert zerlegen und zuordnen kannst.
Wenn alle Spieler dann dieselbe Karten-DLL haben, ist das kein Problem.

zurückgezogen - zuviele Köche...

naja - ich kanns doch nicht lassen.
Also du hast jetzt 2 grundlegende Möglichkeiten: Sowas wie Serialisierung, gewissermassen Parsen/Formatieren in/aus einem Stream.

Oder klassisches Parsen/Formatieren in/aus einem String.
Hier würde ich empfehlen, einfach dem Muster zu folgen, wassich in Hex-Zahlen?-post#2 herausarbeite, und also ebenso deiner Klasse eine statische Parse-Function angedeien lassen.

Abraten täte ich, die klasse durch weitere Felder redundant aufzublähen: Wenn eine Name-Property, dann solls eine berechnete Property sein, etwaAber findich auch nicht nötig, weil das könnte auch die ToString-Überschreibung abhandeln.

Ich hab mal deine Klasse genommen und etwas dran rumgespielt. Rausgekommen ist das:
Was habe ich gemacht?:
-Bei den Enums hat jeder Punkt einen eigenen Integer zugewiesen bekommen
-Ein paar Namen wurden geändert, bsp. Karte.Kartenwert -> Karte.Wert
-Die Funktion GenerateAllCards wurde hinzugefügt, sie generiert alle verfügbaren Karten
-Die Funktionen ToString und FromString wurden hinzugefügt, sie wandeln eine Karte in einen String und wieder zurück
-Die Funktionen ToInt und FromInt wurden hinzugefügt, sie wandeln eine Karte in einen Integer und wieder zurück

Verwendungsbeispiel:

So habe mal mit euren Ideen mal eben selber 2 Methoden geschrieben, wollte mal fragen, was ihr davon haltet ?

Methode 1:


Methode 2:

BinaryFormatter, wie vorgeschlagen. Tüftel gerade noch bissl daran, dass der Server das serializedObject auch mal zu den Clients absendet^^

Nimm doch gleich meine Methode mit dem ToInt bzw. FromInt, damit geht das auch ganz gut, außerdem hast du kleinere Datenmengen zu übermitteln.

Wenn man sich den Längenunterschied des Strings von den Binaryformatter und der anderen Methode anguckst, dann überträgt man ja mit der .ToInt Methode nur einen String von 2 Zahlen, was ja wahrlich kürzer ist. Außerdem wundert es mich, wieso du in den Enumerationen den Werten extra Zahlen zuweist, wenn sie schon von Haus aus "enumeriert" werden.

Enums sind Zahlen, du kannst z.B. festlegen welcher Datentyp für das Enum verwendet werden soll (Byte, Integer, Long,... alle Ganzzahl-Typen eben):



Byte würde für deine Zwecke schon ausreichen, damit kannst du 2^8 verschiedene Zustände speichern (bzw wenn du sie kombinieren willst nur 8, tust du aber nicht).
Im Endeffekt heißt das, dass du lediglich je 1 Byte für Farbe und Wert versenden müsstest um eine Karte eindeutig zu identifizieren. Natürlich nur, wenn du auf Byte-Ebene arbeitest und keine Strings hin und her schickst.

lg

@FreakJNS
Wenn man bei meiner .ToInt-Funktion den Ausgabetyp zu Byte ändert, passt beides sogar zusammen in einen Byte :P.

@Julius
Erstmal sind Enumerationen von Haus aus von 0 - n nummeriert, ich habe die Nummerierung einfach zu 1 - n geändert, da dann die Methoden .ToInt und .FromInt einfacher umzusetzen waren.

Julius schrieb:

Außerdem wundert es mich, wieso du in den Enumerationen den Werten extra Zahlen zuweist, wenn sie schon von Haus aus "enumeriert" werden.

richtig - die Enumerationen waren vorher besser:
Die Werte fingen bei 0 an und waren dem Kartenwert entsprechend geordnet, also Pik war höher als Karo - dassis hier ein wichtiges Detail des Datenmodells.

---

@Julius:: Wenn du eine Methode "Serialize" oder so ähnlich benennst, dann sollte die auch serialisieren. Deine Methoden serialisieren nicht, sondern Formatieren und Parsen.
wirklich empfehlung: Halte dich an übliche Pattern: Formatieren geht mit einer Tostring-Überschreibung und Parsen sei eine Public Shared Function, die einen String nimmt, und eine Karte zurückgibt.
Wie bei Integer, DateTime, Boolean und vielen anneren Klassen auch.

---

Das ganz zugrunde liegende Design, also dass Karte eine Klasse mit 2 Enumerationen ist, würde ich jetzt erstmal nicht weiter diskutieren.
Da sind zig weitere Varianten denkbar, alle mit Vor- und Nach-Teilen - etwa, ob eine Karte nicht besser eine Structure sei?
Oder wie wärs mit einer geflaggten Enumeration - da könnteman die Klasse Karte auch ganz weglassen?

wie gesagt: sowas jetzt erstma nicht ausdiskutieren - da kommste von Höcksken auf Stöcksken.
Das derzeitige Design ist so auch i.O. und brauchbar.

@ErfinderDesRades
Was ist daran so schlimm, wenn man den Enumerationen einen eigenen Wert zuweist? Die genaue Zuweisung kann man ja auch ändern.

prinzipiell nix dagegen - beinem geflaggten Enum wäre das sogar notwendig.

Das Prob habichdoch bereits gesagt: Bei deine Enums hat Karo einen höheren Wert als Pik - und dassis ein nicht-stimmiges Datenmodell eines Kartenspiels.
Enums dienen ja auch < / > - Vergleichen, und Karo muß das niedrigste sein.

Ich würde nur die .toString-Methode nicht dafür 'Missbrauchen' - sie wird ja von etlichen Controls benutzt um ein Objekt sinnvoll anzeigen zu können. Das macht man sich kaputt, weil in einer Listbox würde ich gerne eine schön formatierte Ausgabe wie "Bauer (rot)" lesen und nicht das, was zum speichern erzeugt wird (ist ja vorzugsweise praktisch, nicht schön).

Ich würde also dafür separate Methoden schreiben: Public Function ExportToString() as String und Public Shared ImportFromString(input as String) as Karte
(oder eben toBytes und fromBytes xD)

tja, und ich würd grad ToString brauchen, weil Double, Integer, DateTime, Boolean und weitere gebrauchen ja auch die .Tostring-Überschreibung.

Also wo immer man eine Parse-Function hat, da kann man auch mit .ToString formatieren.

Wenn man wie FreakJNS bei der ToString-Methode sowas wie Bauer (Kreuz) haben möchte, geht das doch auch, man muss nur den Parser etwas anders schreiben :D. Man könnte aber auch bei der .ToString-Methode die Möglichkeit hinzufügen, den String nach Belieben zu formatieren, bei der .FromString-Methode ebenfalls. Die Formatierungen könnte man ja so wie bei String.Format() machen. Die Funktion würde dann so aussehen:
Dafür kannst du dann verschiedene Formate selber erstellen, hier ein paar Beispiele:
{Wert} ({Farbe}) -> König (Herz)
{Farbe} {Wert} -> Herz König
{Farbe: "{Farbe}"; Wert: "{Wert}"} -> {Farbe: "Herz"; Wert: "König"}
Dadurch sollte dir auch das System klar geworden sein, {Wert} und {Farbe} stellen die beiden Eigenschaften der Karte dar.

nafets3646 schrieb:

Die Funktion würde dann so aussehen:

Wozu brauchst Du bei ToString RegEx?
Mach es immer so einfach wie möglich, z.B.: