Aufrechterhaltung der Modularität in Main()?

Question

Ich schreibe das einfache Kartenspiel "War" für Hausaufgaben und jetzt, da das Spiel funktioniert, versuche ich, es modularer und organisierter zu machen. Unten ist ein Abschnitt von Main(), der den Großteil des Programms enthält. Ich sollte erwähnen, dass der Kurs in C# unterrichtet wird, aber es ist kein C# -Kurs. Stattdessen lernen wir grundlegende Logik- und OOP-Konzepte, damit ich einige C# -Funktionen nicht nutzen kann.

bool sameCard = true; 

while (sameCard) 
{ 
    sameCard = false; 
    card1.setVal(random.Next(1,14));  // set card value 
    val1 = determineFace(card1.getVal()); // assign 'face' cards accordingly 
    suit = suitArr[random.Next(0,4)];  // choose suit string from array 
    card1.setSuit(suit);     // set card suit 
    card2.setVal(random.Next(1,14));  // rinse, repeat for card2... 
    val2 = determineFace(card2.getVal());  
    suit = suitArr[random.Next(0,4)];   
    card2.setSuit(suit); 

    // check if same card is drawn twice: 

    catchDuplicate(ref card1, ref card2, ref sameCard); 
} 
Console.WriteLine ("Player: {0} of {1}", val1, card1.getSuit()); 
Console.WriteLine ("Computer: {0} of {1}", val2, card2.getSuit()); 

// compare card values, display winner: 

determineWinner(card1, card2); 

hier sind also meine Fragen:

• Kann ich Schleifen in Main() und es noch modular in Betracht ziehen?
• Ist der Kartenzeichnungsprozess richtig geschrieben/enthalten?
• Wird es als schlechte Praxis angesehen, Nachrichten in einer Methode zu drucken (z. B. determineWinner())?

Ich habe nur für zwei Semester programmiert und ich möchte in diesem Stadium gute Gewohnheiten bilden. Jede Eingabe/Beratung würde sehr geschätzt werden.

Edit:

catchDuplicate() ist nun ein boolean Methode und der Aufruf sieht wie folgt aus:

sameCard = catchDuplicate(card1, card2);

dank @Douglas.

Answer 1

Kann ich Schleifen in Main() verwenden und immer noch als modular betrachten?

Ja, Sie können. Meistens enthält Main in OOP-Programmen jedoch nur eine Handvoll Methodenaufrufe, die die Kernfunktionalität initiieren, die dann in anderen Klassen gespeichert wird.

Ist der Kartenzeichnungsprozess richtig geschrieben/enthalten?

Teilweise. Wenn ich Ihren Code richtig verstehe (Sie zeigen nur Main), führen Sie einige Aktionen durch, die, wenn sie in der falschen Reihenfolge oder mit den falschen Werten ausgeführt werden, nicht gut enden. Stellen Sie sich Folgendes vor: Wenn Sie Ihre Klassenbibliothek verkaufen (nicht das gesamte Produkt, aber nur Ihre Klassen), was wäre der beste Weg, Ihre Bibliothek für einen nicht initiierten Benutzer zu verwenden?

I.e., betrachte eine Klasse Deck, die ein Kartenspiel enthält. Bei der Erstellung werden alle Karten erstellt und gemischt. Geben Sie ihm eine Methode Shuffle, um das Deck zu mischen, wenn der Benutzer Ihrer Klasse mischen muss und fügen Sie Methoden wie DrawCard für die Behandlung von Karten hinzu.

weiter: Sie haben Methoden, die noch Funktionalität innerhalb einer Klasse für sich nicht enthalten sind, besser in einer Klasse sein würde. Das heißt, ist besser geeignet determineFace Verfahren auf Klasse zu sein Card (card2 vorausgesetzt ist vom Typ Card).

Wird es als schlechte Praxis angesehen, Nachrichten in einer Methode zu drucken (z. B. deatcheWinner())?

Ja und nein. Wenn Nachrichten nur während des Tests angezeigt werden sollen, verwenden Sie Debug.WriteLine. In einem Produktions-Build sind dies No-Ops. Stellen Sie jedoch sicher, dass das aus dem Name der Methode klar ist, wenn Sie Nachrichten in einer Produktionsversion schreiben. Ie., WriteWinnerToConsole oder etwas.

Es ist häufiger nicht tun Sie dies, weil: In welchem ​​Format würden Sie die Informationen drucken? Welcher Text sollte dabei sein? Wie gehst du mit Lokalisierung um? Wenn Sie jedoch ein Programm schreiben, muss es natürlich Methoden enthalten, die Daten auf den Bildschirm (oder das Formular oder die Webseite) schreiben. Diese sind normalerweise in bestimmten Klassen für diesen Zweck enthalten. Hier könnte das zum Beispiel die Klasse CardGameX sein.

Allgemeine Gedanken
über das Prinzip Denken „eine Methode/Funktion nur eine Aufgabe nur und eine Aufgabe haben, und es soll Nebenwirkungen nicht (hat wie Quadrat Berechnung und Druck, dann druckt die Nebenwirkung). "

Das Prinzip für die Klassen ist, auf sehr hohe Niveau: eine Klasse enthält Methoden, die logisch zusammengehören und auf dem gleichen Satz von Eigenschaften/Feldern arbeiten. Ein Beispiel für das Gegenteil: Shuffle sollte keine Methode in Klasse Card sein. Es würde jedoch logisch in die Klasse Deck gehören.

Answer 2

Wenn das Hauptproblem Ihrer Hausaufgaben eine modulare Anwendung erstellen, müssen Sie alle Logik in spezialisierten Klassen kapseln. Jede Klasse muss nur einen Job ausführen. Funktion, die mit der Karte spielen, muss in einer Kartenklasse sein. Funktion, die Karten zieht, sollte eine andere Klasse sein.

Ich denke, es ist das Ziel Ihrer Hausaufgaben, viel Glück!

Answer 3

Q: Kann ich Schleifen in Main() verwenden und immer noch als modular betrachten?

A: Ja, Sie können Schleifen verwenden, die sich nicht wirklich auf die Modularität auswirken.

F: Ist der Kartenzeichnungsprozess richtig geschrieben/enthalten?

A: Wenn Sie modularer sein wollen, verwandeln Sie DrawCard in eine Funktion/Methode. Vielleicht schreibe DrawCards statt DrawCard, aber dann gibt es dort eine Optimierungs-Modularitäts-Frage.

F: Wird es als schlechte Methode angesehen, Nachrichten in einer Methode zu drucken (zB detenetWinner())?

A: Ich würde nicht sagen, Drucken von Nachrichten in einer Methode ist schlechte Praxis, es hängt nur vom Kontext ab. Im Idealfall behandelt das Spiel selbst nichts außer Spiellogik. Das Programm kann irgendeine Art von Spielobjekt haben und es kann den Status vom Spielobjekt lesen. Auf diese Weise könnten Sie das Spiel technisch von einer textbasierten zu einer grafischen Version ändern. Ich meine, das ist ideal für die Modularität, aber bei einer Deadline ist das vielleicht nicht praktikabel. Sie müssen immer entscheiden, wann Sie eine Best Practice opfern müssen, weil es nicht genug Zeit gibt. Leider ist dies nur allzu oft der Fall.

Separate Spiel Logik von der Präsentation von ihm. Mit einem einfachen Spiel wie diesem ist es eine unnötige Abhängigkeit.

Answer 4

Nehmen Sie alle Ratschläge zu "Best Practices" mit einem Körnchen Salz. Denk immer an dich selbst.

Das heißt:

• Kann ich Schleifen in Main() und betrachten noch modular es?

Die beiden Konzepte sind unabhängig. Wenn Ihr Main() nur High-Level-Logik (d. H. Ruft andere Methoden), dann ist es egal, ob es in einer Schleife tut, nachdem der Algorithmus eine Schleife erfordert. (Sie würden keine Schleife unnötig hinzufügen, nein?)

Als Faustregel, wenn möglich/praktisch, machen Sie Ihr Programm selbstdokumentieren. Machen Sie es "lesbar", wenn eine neue Person (oder Sie selbst, in ein paar Monaten) es betrachtet, können sie es auf jeder Ebene verstehen.

• Ist der Kartenzeichnungsprozess richtig geschrieben/enthalten?

Nein. Zunächst einmal sollte eine Karte niemals zweimal ausgewählt werden. Für einen „modularen“ Ansatz würde ich so etwas wie dieses:

while (Deck.NumCards >= 2) 
{ 
    Card card1 = Deck.GetACard(); 
    Card card2 = Deck.GetACard(); 
    PrintSomeStuffAboutACard(GetWinner(card1, card2)); 
} 

• Ist es schlechte Praxis betrachtet Nachrichten in einem Verfahren zu drucken (dh: determineWinner())?

Ist der Zweck eine Nachricht zu drucken? Wenn die Antwort "Nein" lautet, dann handelt es sich nicht um eine "schlechte Übung", Sie funktionieren einfach falsch.

Das heißt, es gibt so etwas wie ein "Debug" Build und ein "Release" Build. Um Ihnen beim Debuggen der Anwendung zu helfen und herauszufinden, was funktioniert und was nicht, sollten Sie Logging-Nachrichten hinzufügen.

Stellen Sie sicher, dass sie relevant sind und nicht im Build "release" ausgeführt werden.