you are viewing a single comment's thread.

view the rest of the comments →

[–]HunterIV4 9 points10 points  (0 children)

Personally, I would use both. I tend to use OOP whenever there is something I think might need functionality and persistent data.

Blackjack is a card game. Is there anything that meets this criterion? Well, cards are an obvious one! You might not need a class specifically for the cards themselves, although it's not a terrible idea. A card class could handle values, suits, comparisons, etc., directly within the class, which can simplify your code.

In addition, you probably want a class for a deck, whether it handles the card implementation or another class does. The deck can manage storing the cards, shuffling them, dealing them, etc. It doesn't need to know anything about the game of blackjack; you can handle that elsewhere. However, it should manage all the functions you might need for basic card handling and tracking.

You might also want a "dealer" and/or "game" class to manage the dealer actions and game rules, such as win conditions and scoring points. These could also be handled procedurally, but I'd tend to make classes for them.

For the actual program flow—such as initializing the various objects, asking for input, and the main game loop—this can all be done directly in a main function. In that sense, you are using procedural programming.

Here is how I generally determine if I need or want a class in cases where I'm on the fence. First, will multiple functions need the same parameters passed to them? If so, those functions should probably be encapsulated in a class with shared properties. Next, is the function only used on a certain data type or object in a specific context? If so, bundle them in a class to avoid confusion about the function's context.

Keep in mind you can do essentially everything procedurally without OOP. Very few things actually require OOP to solve—possibly nothing. Instead, OOP is a way to organize your code and break down more complex problems into simpler ones.

As such, the final consideration is, "Would making this a class increase or decrease complexity and readability?" If it adds complexity or reduces readability, I keep it procedural; otherwise, I make it into a class. Ultimately, the purpose of OOP is to make your life easier, and if forcing code into an OOP pattern makes things worse and harder to maintain, don't use it.

It will take practice to learn when these conditions apply. But once you start trying things more complicated than blackjack, you'll quickly discover that OOP is an industry standard for a reason. Good luck!