Learning OOP

[Saikrishnan Srivatsan]

I am new to OO design and would like to get better at it by designing applications. Could you please suggest some sample applications?

[Stephan van Hulst]

Build a board game!

[Michael Gomez]

Make a card game, some classes might include:
*Card (52 possible cards)
*Suit (enum)
*Deck (methods might include .shuffle() )
*Player (name, AI to control card selection)
*Game (keep score over multiple rounds)
*Hand (5 cards per hand)
*Round (1 round of play)

Make it play poker or any other card variant.
Start by making it command line based, bonus points for making it a GUI.

[Saikrishnan Srivatsan]

Thanks . I just built a noughts and crosses game as part of a course. I thought I will do something other than a board game.

[Saikrishnan Srivatsan]

Thank you. Before asking this question I'd started working on an address book a couple of days ago. I have posted that design in this thread:
https://coderanch.com/t/626812/java/java/Designing-address-book-Java#2867527

Please take a look and comment. Meanwhile, I will start working on the card game as well.

[Saikrishnan Srivatsan]

I've started building the card game. For the moment, I've just designed a deck of cards. Here are my classes:

Deck
Attributes: Card (array of 52 cards)
Methods: shuffle(), getCard()

Card
Attributes - Rank, Suit
Methods - getRank(), getSuit()

Rank - enum

Suit - enum

Please review and comment. I will work on the game once someone approves the design.

[Javaman Codington]

Try building an application that counts numbers using a for loop, has methods, print statements, and adds up the sum of those numbers.

[Stephan van Hulst]

Saikrishnan, I would question the use of a Deck class. If you have an application that requires a deck of cards, they can probably use one of the Collection classes. You could however create a utility class that generates standard decks, or just provide the Card class with a utility method. Example, add the following method to your Card class (or a utility class such as Cards):

public static final List<Card> createStandardDeck(boolean hasJokers) {

This method generates all 52 standard playing cards and optionally adds three joker cards.

Now, if you have a class such as Solitaire, it could look like this:

public final class Solitaire {
  
  private final Deque<Card> stack;

  ...

  public Solitaire() {
    List<Card> deck = Cards.createStandardDeck(false);
    Collections.shuffle(deck);
    stack = new LinkedList(deck);
    ...
  }

  ...

}

[Saikrishnan Srivatsan]

Thanks Stephan. Do you question my Deck class because card isn't really an "attribute" of deck? Is that why I should have just a helper class to generate a deck of cards and also provide methods like shuffle in that class?

[Winston Gutkowski]

Saikrishnan Srivatsan wrote:Thanks Stephan. Do you question my Deck class because card isn't really an "attribute" of deck?

I think it's more that "deck" is an ambiguous term, unless you specifically mean it as a single deck of standard playing cards. A "deck" for Happy Families will be completely different to a deck for Bridge or Texas Holdem; and many games (eg, Blackjack) use multi-deck "shoes", which are likely to need the same shuffle() and deal() methods.

HIH

Winston

[Saikrishnan Srivatsan]

Thanks Winston. Yes, I intended for the deck to mean a deck of cards specifically when I wrote it. Now I am slightly confused if card is really an "attribute" of the deck class. A deck doesn't exist before a card is created unlike an address book which still exists even before any entries are stored in it. In cases like these, can it still be an attribute?

[Winston Gutkowski]

Saikrishnan Srivatsan wrote:Thanks Winston. Yes, I intended for the deck to mean a deck of cards specifically when I wrote it. Now I am slightly confused if card is really an "attribute" of the deck class. A deck doesn't exist before a card is created unlike an address book which still exists even before any entries are stored in it. In cases like these, can it still be an attribute?

Well, I think, in class terms, you're talking about separate entities. A Card may be a member (ie, part of) of a Deck, but it's definition stands alone. Indeed, different types of cards are likely to be the main reason for different types of Deck; but not entirely - there are several games that use standard playing cards that don't use all 54 cards (not 52) - 66 being just one - or that involve the Jokers (I hope you remembered them), like Canasta.

So your observation is quite correct: a Deck can't exist without a Card. But maybe you've missed out another important relationship: it is also specified by the Game.

HIH (probably not )

Winston

[Stephan van Hulst]

Saikrishnan Srivatsan wrote:Thanks Stephan. Do you question my Deck class because card isn't really an "attribute" of deck? Is that why I should have just a helper class to generate a deck of cards and also provide methods like shuffle in that class?

No, I'm questioning the use of a Deck class, because it won't be able to do anything that Java's standard collections can't do. For instance, you can use a LinkedList or ArrayDeque for pretty much anything you would do with a bunch of cards.

[Saikrishnan Srivatsan]

Winston Gutkowski wrote:But maybe you've missed out another important relationship: it is also specified by the Game.Winston

Sorry, I don't understand what I've missed Winston Also, card being an attribute of the Deck class is wrong?

[Winston Gutkowski]

Saikrishnan Srivatsan wrote:Sorry, I don't understand what I've missed Winston Also, card being an attribute of the Deck class is wrong?

Erm...what don't you understand?

A "deck", as Stephan rightly said, is simply a collection (actually, more likely, a Set (see java.util.Set)) of Cards. However, if you're trying to analyse it in data terms, then there's a bit more going on.

There may be pre-determined "packs" (and I use the term advisedly) of Cards, but the "deck" is usually the set of Cards you actually play with in a particular Game; and in some games (usually when there's more than one deck involved) it's called a "shoe".

So, for that reason alone, I would say that a Card is not an attribute of a Deck.

The fact is that everything starts with the Card, so create a public class for that. You can decide later on exactly where it should be put if you think you need to. As to the semantic distinctions of Pack and Deck and Shoe, I leave it up to you - although I'd say that the last two are probably synonymous, since they both generally refer to "the set of cards used to play a game".

Perhaps the problem is that what you call a "deck", I'd call a "pack".

Winston

[Stephan van Hulst]

Winston Gutkowski wrote:(actually, more likely, a Set (see java.util.Set))

Disagree! There are good reasons to make Cards with the same suit and rank equal. This does not mean that a particular game may only have one of each. Think Canasta

[Jesper de Jong]

One thing to keep in mind when creating a design is that there isn't one correct or perfect answer; you can design the same program in many different ways, which are all equally valid.

I once did a workshop with a room full of programmers, in which we all designed our own version of Conway's Game of Life (everybody using his or her own favorite programming language). It was interesting to see the many different ideas people had for designing their application. There are many ways you can model the board, the cells and the logic of the program.

[Winston Gutkowski]

Stephan van Hulst wrote:Disagree! There are good reasons to make Cards with the same suit and rank equal. This does not mean that a particular game may only have one of each. Think Canasta

Quite right. So a Deck (if you take my definition) is not a Set, but a Pack probably is. In fact I think there are even games that distinguish between the "red" and "black" Joker.

Ain't design fun?

Winston

[Prasanna Raman]

Winston Gutkowski wrote:Perhaps the problem is that what you call a "deck", I'd call a "pack".

If the original poster had used the name "Pack" instead of "Deck", is it still wrong to have a Card attribute inside the Pack class?

[Stephan van Hulst]

Wrong, no. But I still doubt the usefulness.

[Saikrishnan Srivatsan]

Thank you for all the comments. I've designed a pack of cards. Please review and comment.

public enum Rank {

    ACE("A", 1), TWO("2", 2), THREE("3", 3), FOUR("4", 4), FIVE("5", 5),
    SIX("6", 6), SEVEN("7", 7), EIGHT("8", 8), NINE("9", 9), TEN("10", 10),
    JACK("J", 11), QUEEN("Q", 12), KING("K", 13);
    
    private int value;
    private String name;

    Rank(String name, int value) {
        this.name = name;
        this.value = value;
    }
    
    public int getValue() {
        return value;
    }
    
    public String getName() {
        return name;
    }
    
    @Override
    public String toString() {
        return name;
    }
    
    
}

public enum Suit {
    
    SPADES('\u2660'), HEARTS ('\u2665'), DIAMONDS('\u2666'), 
            CLUBS('\u2663'); 
    
    char symbol;
    
    Suit(char symbol) {
        this.symbol = symbol;
    }
    
    public char getSymbol() {
        return symbol;
    }
    
    @Override
    public String toString() {
        return ((Character) symbol).toString();
    }
    
    
}

public class Card {
    
    private final Rank rank;
    private final Suit suit;
    
    Card(Rank rank, Suit suit) {
        this.rank = rank;
        this.suit = suit;
    }
    
    Rank getRank() {
        return rank;
    }
    
    Suit getSuit() {
        return suit;
    }
    
    @Override
    public String toString() {
        return rank + "" + suit;
    }
    
}

public class Pack {
    
    List<Card> cards;
    
    Pack() {
        cards = new ArrayList<>(52);
    }
    
    void shuffle() {
        Collections.shuffle(cards);
    }
    
    
    
}

[Stephan van Hulst]

First of all, I wouldn't give Ranks a value. Card values are properties of specific card games, not of the cards themselves.

For your Suit enum, why are you not embedding the symbols in Strings directly? "\u2660" versus '\u2660'. I would also not return these characters in the toString() method, because toString() is often used for debugging purposes, and not all viewers display such symbols correctly.

For future reference, if you need to convert a char to a String, use Character.toString(char).

You're not doing any parameter checking on your Card class. What if a user constructs a card with null values?

I don't mean this in a rude way, but your Pack class is pretty useless. Right now it's just a wrapper around a list, which does nothing else than provide a layer of indirection.

[Saikrishnan Srivatsan]

Stephan van Hulst wrote:First of all, I wouldn't give Ranks a value. Card values are properties of specific card games, not of the cards themselves.

Agreed, thanks. I've got rid of the values.

Stephan van Hulst wrote:For your Suit enum, why are you not embedding the symbols in Strings directly? "\u2660" versus '\u2660'. I would also not return these characters in the toString() method, because toString() is often used for debugging purposes, and not all viewers display such symbols correctly.

I've removed the toString() methods and changed the unicode characters to strings.

Stephan van Hulst wrote:You're not doing any parameter checking on your Card class. What if a user constructs a card with null values?

When I'm designing a just the pack of cards and not an actual game, I thought I'd create all the cards in my program and give it to the user. So, I didn't think of a user creating a card.

Stephan van Hulst wrote:I don't mean this in a rude way, but your Pack class is pretty useless. Right now it's just a wrapper around a list, which does nothing else than provide a layer of indirection.

OK, thank you for pointing this out. My intention first was just to design a pack of cards correctly, and not a game. So I just used that class to hold my cards. I'll get rid of that when I start doing the game.

If this design looks good, I am thinking of building a game (Blackjack?). Is that a good place to start?

[Stephan van Hulst]

By user I mean the user of your Card class, which in this case would be the game class. What would it mean for the Card to be constructed with null values? If it doesn't mean anything, you should make it illegal to do so. Use Objects.requireNonNull(suit) and Objects.requireNonNull(rank) to check the parameters in the constructor.

Yes, creating a game like Blackjack would be perfect. You could do any game you enjoyed, really.

[Junilu Lacar]

I don't really see a problem with "Deck". You have to separate the problem domain concept (deck of cards) from the implementation (the Deque interface) -- they are two very different things. If you're talking about a card game, then "deck" is usually understood as referring to a "standard deck of 52 cards". I guess you could use "StandardDeck" if you think you might have some reason to differentiate it from other "non-standard" decks. When you use "Pack" to refer to a Deck of cards, you start adding cognitive load: some people will have to translate "Pack" to "Deck", just like some people have to translate "boot" to "trunk" or vice versa when referring to the compartment in the back of a car (or automobile, if you like). On the other hand, if you use Pack to mean the standard deck of 52 playing cards + some Jokers, and Deck to mean just the 52 playing cards, then be sure to document that prominently in your code and make sure you have a good reason to make that distinction.

As for the question "Is a Card an attribute of Deck?" look up aggregation vs composition

I think you are getting too hung up on trying to think of your "objects" in terms of their attributes. I have found that it's better to start with *behaviors* instead because that's the more important aspect of OOP. When you focus too much on attributes and data, there's a tendency to over-think the design.

I suggest you start with some CRC (Class-Responsibility-Collaborator) analysis. First, figure out a piece of functionality or behavior that you want to implement. Then identify some high-level *candidate* objects that might be needed to provide that behavior. Then identify different aspects of the functionality that different candidate classes would be responsible for providing. Then see how these different classes collaborate with each other to provide the entire functionality. As you go through this thought process, you start identifying the attributes/data that each class needs to encapsulate.

Lastly, I suggest that you don't spend too much time *thinking* about the design. I'm very partial to Test-Driven Development and I find it's best to just start with a high-level CRC mapping. Then I use unit tests to drive my design thinking. Your first design ideas are usually not the best ones when it comes to designing a system because there is so much you don't/can't think of up front. In my experience, incrementally writing unit tests and working code gives you the best feedback in fleshing out the detailed design.

So, what kind of card game is it that you want to implement? In a Python class I took last year on Coursera.org, one of the assignments we had was to implement the "Memory Game" using a standard deck of cards. I found it a great exercise in OOP design and TDD.

[Ajitesh Shukla]

My two cents.. get hang of "Single Responsibility Principle" that belongs to SOLID set of principles and you could see a notch improvement in designing and developing code using OOP.

[Saikrishnan Srivatsan]

Thanks all, for your valuable suggestions

I have started a new topic on implementing Blackjack here: https://coderanch.com/t/627988/java/java/Implementing-Blackjack#2873645

Please take a look and comment.