Maintaining modularity in Main ()?
I am writing a simple War card game for homework, and now that the game is working, I am trying to make it more modular and organized. Below is a section Main()
containing the main part of the program. It should be noted that the course is taught in C #, but this is not a C # course. Rather, we are learning basic OOP logic and concepts, so I cannot use some of the C # features.
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);
So here are my questions:
- Can I use loops in Main () and still consider it modular?
- Is the map drawing process well written / contained correctly?
- Is it bad practice to print messages in a method (i.e.
determineWinner()
)?
I have only programmed for two semesters and I would like to form good habits at this stage. Any input / advice would be much appreciated.
Edit:
catchDuplicate () is now a boolean method and the call looks like this:
sameCard = catchDuplicate(card1, card2);
thanks to @Douglas.
source to share
Can I use loops in Main () and still consider it modular?
Yes, you can. However, more often than not, Main
OOP programs contain only a few method calls that initiate basic functionality that is then stored in other classes.
Is the map drawing process correct / correct?
Partially. If I understand your code correctly (you only show Main
), you are taking some actions that, if done in the wrong order or with the wrong values, may not end well. Think of it this way: If you are selling your class library (not the entire product, but just your classes), what would be the best way to use your library for the uninitiated user?
Ie, consider a class Deck
containing a deck of cards. On creation, he creates all the cards and shuffles them. Give it a method Shuffle
to shuffle the deck when the user of your class needs to shuffle and add methods like DrawCard
for handling cards.
Next: you have methods that are not contained in their own class, but have functionality that would be better in the class. Ie is determineFace
best for a class method Card
(assuming it card2
has a type Card
).
Is it bad practice to print messages in a method (i.e.: defineWinner ())?
Yes and no. If you want messages to be visible during testing, use Debug.WriteLine
. In a production build, they won't work. However, when writing messages in production, make sure it's clear from the method name. Ie, WriteWinnerToConsole
or something else.
Most often, you don't do this, because: in what format will you print the information? What text should be with it? How do you deal with localization? However, when you write a program, obviously it must contain methods that write stuff to the screen (or form, or web page). For this purpose, they are usually kept in specific classes. There could be a class CardGameX
, for example.
General Thoughts
Think of the principle: "One method / function should only have one task and one task, and it should not have side effects (eg calculating the square and printing and then printing is a side effect)."
The principle for classes is very high: a class contains methods that logically belong to each other and work with the same set of properties / fields. An example of the opposite: Shuffle
Should not be a class method Card
. However, it will belong logically in the class Deck
.
source to share
If the main problem with your homework is creating a modular application, you should encapsulate all the logic in specialized classes. Each class must do only one task. The function playing with the card must be in the card class. The function that draws the maps must be a different class.
I think this is the purpose of your homework, good luck!
source to share
Take all the "best practice" tips with a grain of salt. Always think about yourself.
That said:
- Can I use loops in Main () and still consider it modular?
The two concepts are independent. If your Main () only executes high-level logic (i.e., calls other methods), then it doesn't matter if it does it in a loop, because the algorithm requires a loop. (you wouldn't add a loop unnecessarily, would you?)
Generally, if possible / practical, make your program self-documenting. Make it readable, so if a new person (or even you, a few months after that) looks at it, they can understand it at any level.
- Is the map drawing process well written / contained correctly?
Not. First of all, the card cannot be chosen twice. For a more "modular" approach, I would have something like this:
while ( Deck.NumCards >= 2 )
{
Card card1 = Deck.GetACard();
Card card2 = Deck.GetACard();
PrintSomeStuffAboutACard( GetWinner( card1, card2 ) );
}
- Is it considered bad practice to print messages in a method (i.e. defineWinner ())?
Destination determineWinner
to print a message? If the answer is "No", then it is not a question of "bad practice", you are performing the functions incorrectly.
However, there is such a thing as a "debug" build and a "release" build. To help you debug your application and figure out what works and what doesn't, it's a good idea to add logging messages.
Make sure they are relevant and that they are not run in the "release" build.
source to share
Q: Can I use contours in Main () and still consider it modular?
A: Yes, you can use loops that don't really affect modularity.
Q: Is the graphic design of the map written / compiled correctly?
A: If you want to be more modular, turn DrawCard into a function / method. Maybe just write DrawCards instead of DrawCard, but there is a question about optimization and modularity.
Q: Is it bad practice to print messages in a method (i.e. defineWinner ())?
A: I would not say that printed messages in a method are bad practice, it just depends on the context. Ideally, the game itself doesn't handle anything other than the logic of the game. The program can have some kind of game object and can read the state from the game object. This way you can technically change the game from text to graphical. I mean this ideal is for modularity, but it might not be practical given the deadline. You always have to decide when you need to sacrifice best practice because time isn't enough. Unfortunately, this is all too often common.
Separate the logic of the game from its presentation. With a simple game like this, it's an extra addiction.
source to share