BlackJack: Starting to code

[Pete Letkeman]

We now have some objects briefly outline some of the objects which we think that we would need for game as shown here.
I think it may be time to start coding/programming. If we start with the smallest object, then we start with the Card object.
Each card has a rank, numeric value, and suit. In BlackJack, the Ace can have two different values (one and eleven), any face card has a value of ten, the other card's numeric value is their face value.
Rank and Suit could be defined with enums. Both decks and hands have collections of cards.

This is what I have for my card class:
Card.java

package coderanch.cards;

import java.util.Objects;

public class Card {
    private Rank rank;
    private Suit suit;

    public Rank getRank() {
        return rank;
    }

    public void setRank(Rank rank) {
        this.rank = rank;
    }

    public Suit getSuit() {
        return suit;
    }

    public void setSuit(Suit suit) {
        this.suit = suit;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (!(o instanceof Card)) {
            return false;
        }
        Card card = (Card) o;
        return getRank() == card.getRank() &&
                getSuit() == card.getSuit();
    }

    @Override
    public int hashCode() {
        return Objects.hash(getRank(), getSuit());
    }

    @Override
    public String toString() {
        return "Card{" +
                "rank=" + rank +
                ", suit=" + suit +
                '}';
    }
}

We will be sorting, comparing cards and getting their value. So we'll need to override the equals method as shown above.
If you override the equals method then you need to override the hashCode method as explained here.
There are various algorithms which can be used to generate the a hashCode value. I simply used the method implantation provided by my IDE.

The default implementation of the toString() method is not too useful for us. It will probably print out something like objecttype@hexvalue.
It's useful to override this method at least for debug purposes if nothing else.

Here is a base skeleton for a deck object:
Deck.java

package coderanch.cards;

import java.util.ArrayList;
import java.util.List;
import java.util.Objects;

public class Deck {
    public static final int NUMBER_OF_CARDS = 52;

    private List<Card> cards;

    public Deck(List<Card> cards) {
        this.cards = cards;
    }

    public Deck() {
    }

    public List<Card> Shuffle() {
        return shuffledDeck();
    }

    private List<Card> shuffledDeck() {
        /* need to randomly order all cards in the deck */
        return new ArrayList<Card>();
    }

    public List<Card> getCards() {
        return cards;
    }

    public void setCards(List<Card> cards) {
        this.cards = cards;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (!(o instanceof Deck)) {
            return false;
        }
        Deck deck = (Deck) o;
        return Objects.equals(getCards(), deck.getCards());
    }

    @Override
    public int hashCode() {
        return Objects.hash(getCards());
    }

    @Override
    public String toString() {
        return "Deck{" +
                "cards=" + cards +
                '}';
    }
}

Notice that I've created the following to methods

   public List<Card> Shuffle() 
   private List<Card> shuffledDeck()

I find sometimes is nice to have as much logic as I can in private methods provided it will not be shared with other members.
This would allow private methods to be totally rewritten without changing the public method too much.

Also notice that List is defined, but ArrayList is used. In doing so I can use both elements of arrays and lists.
Or I could use any other class which implements the list interface fairly easily. This is part of "L" of the SOLID principle.

Streams  have many methods/operations which can make collections (lists) much quicker.
However you may need to know about Lambdas to full advantage of them.

It is totally fine at this point to simply stub out the methods that you may need. Later on you can complete the stubs as you refine your classes.
I suggest that you spend some time defining your classes and stubbing methods as you go. This will give you a better idea of what is needed and how it is used.

When defining your class try to make it as complete and self contained as possible. This is the S in SOLID..
Hopefully you do not end up with a method in the deck class which sums up the values of the cards. Such a method would probably belong to the hand class or some other similar class.

This code will most likely change as I give the project more thought. My code may not be 100% correct either, it should compile fine, but I have not listed or shown all the classes which I would use.
These are only the first couple of classes which are only partially complete. I am also well aware of the fact that some times (more often then I'd like) I create software with bugs.

Lastly, when defining your classes, you should try to limit both access and visibility of not only the class members, but the class itself. You may not need to have everything at with public access and some classes could be final.
There is a whole book named Effective Java which tries to explain some of the best practices.

I'll post my github link to this in a few days to my class definitions.
In the meantime you can define your own classes and implementations for them.
If you have any questions on how to do something then post to the correct forum on CodeRanch and hopefully someone will be able to help you out.

[Liutauras Vilda]

Wouldn't we prefer to initialise card within the constructor and avoid setters? Also we could ensure that parameters within the constructor are passed as intended, meaning there is a rank and there is a suite.

Maybe to have both classes final as well as fields also would make sense? We could remove final in case there would come up situation of such need.

[Stephan van Hulst]

There are a few things I would strongly advise to do differently:

Package names should follow the reverse host name scheme: com.coderanch.cards

Make classes final unless designed for inheritance.

Makes fields final unless designed for mutability.

Don't provide setters unless designed for mutability.

Write documentation. This is not example code, it's actually what's going to be used in a project.

Implement your methods by throwing UnsupportedOperationException, and write tests before you replace the implementation.

Validate your parameters.

Don't use string concatenation. Inside loops, use StringBuilder, and outside loops, use String.format().

Adhere to YAGNI: Why does Deck have a constant NUMBER_OF_CARDS without a clear use case for it?

Deck is a pretty useless wrapper around a list of cards. Whatever class is using a deck of cards can just maintain a collection itself. Advantage is that they can decide the appropriate collection for themselves.

Start method names with lowercase letter: shuffle().

shuffledDeck() returns an empty list.

Why is shuffledDeck() an instance method?

Be consistent in accessing your fields. Use either the field directly, or call the getter, but don't mix it up. See my preferences below.

Some personal preferences:

Nest Rank and Suit inside Card. They are strongly related to Card, and don't mean much outside of the context of a Card.

Don't prefix simple properties with get-. I find rank() and suit() less verbose, and I reserve getFoo() to express that returning a Foo involves more calculation than just returning a field.

Instead of using the getters from within the class, just use the fields directly. Less verbose and saves you a stack frame (not that it really matters).

I like to try and give equatable value types a natural order, if possible. The natural order of cards may not be applicable to all card games, but for most you will at least have a common way to sort a hand.

Inside the equals() method, I like to explicitly refer to this, and name the other instance 'other'. That way, you get code like this.rank == other.rank.

Pete Letkeman wrote:I find sometimes is nice to have as much logic as I can in private methods provided it will not be shared with other members.
This would allow private methods to be totally rewritten without changing the public method too much.

I agree using private methods is good when you need to cut up your methods in smaller pieces, but just writing a private method as an alias for a one-liner is pretty pointless.

However you may need to know about Lambdas to full advantage of them.

Functional code is great for beginners to get into as soon as possible. There are good reasons to use collections over streams, but to avoid lambda expressions is not one of them.

I suggest that you spend some time defining your classes and stubbing methods as you go. This will give you a better idea of what is needed and how it is used.

Agreed, but stub them by throwing UnsupportedOperationException.

[Pete Letkeman]

Great, feedback, exactly what is needed.
There is a lot to take in and I'm glad that both Stephan and Liutauras have responded.
I clearly did not spend enough time with this code before I posted it. However they both bring up very good points.

When you use final you are stopping others from overriding the functionality or values, either intentionally or unintentionally later on. This can be a very good thing.

There is always a balance to be had when using getters and setters and constructors. Some libraries expect a constructor without any parameters.
Many people can use/remember somewhere around five parameters for a method/constructor before the order of the values is mixed up and/or they have to refer back to the documentation.
One way around this limitation people use the Builder design pattern. In your Google search for 'builder site:coderanch.com' to find some of the many discussions around the builder pattern on CodeRanch.

Yes, you should always validate your parameters, a simple IF can save you hours of bug fixes. And no, I have not do that in the provided code.

I will probably remove the 52 card constant before two long. I did have something in mind but that may be something that is better for later on.

As you can see there are plenty of rules/conventions that programmers use. Sometimes even a somewhat experienced programmer can start off wrong.
That said, there are some tools which will help you to see some of the errors that you have created such as Sonar and CheckStyle.
Sonar is a free code quality checker which works with both Eclipse and IntelliJ.
CheckStyle tries to make sure that you follow many of the programming formatting and style rules.
However, a tool is simply a tool, it may not help you learn and you can still create bad code with a tool.  Some tools can even slow down your IDE/system.

You can tell that I did not use any extra tools when creating this code. In not using any extra tools I was able to get some very helpful feedback from some of the members of this web site.
(This was not intentional, but welcomed nonetheless).

[Steven Mcdonald]

Hi pete,
I was also trying to figure out the best way to shuffle a deck and came across Collections.shuffle(), which has two implementations in the docs. I hope this might help with your custom method. Also, speaking of final, since cards will always have one of four suits and one of 13 values; would it be better to make two final enums for the suit and card value? I've implemented a for each with a card constructor using final enums in the code structure I'm trying out. I'm sure the way I'm doing it is probably wrong, as I'm fairly new to this, but would using loops to construct cards inside the deck be better than manual input? It would also enable getting rid of setters for the cards, so that other code can't change card variables like suit or value. I feel that this would help to lower the chance of an invalid value being set in these variables. What do you think?

[Pete Letkeman]

Steven, enums are implicitly final and most IDEs will suggest that you remove the final keyword if used with an enum.

One thing to look out for is defining a final and not setting it's value.
Many people choose to do something like this:

final int MAX_NUM = 10;

however this could be used as well

final int MAX_NUM;
MAX_NUM = 10;

I would suggest that you always assign the final a value when you declare it, this makes it easier to read/follow.

With regards to Collections.shuffle(), this will probably work.
However along with that you should really look into implementing and overriding the equals(), hashCode() and toString() methods in your classes.
For cards your equals() method will most likely only care about the rank of a card and not the suit.
For players your equals() method will care about the total value of the players hand.
The equals() method would most likely be needed for any type of sorting of the cards.
Would the player sort their cards? I know that I sort my cards in nearly every card game I play. So giving the user that option may not be a bad idea.

By the way, I do not know if you pick up on this yet or not, but the Ace can have either a value of 1 or a value of 11.
This means that a hand with the following cards hand would could have more then one value as shown:
Ace + Five + Eight +  Ace 1   +  5   +   8   +   1 11  +  5   +   8   +   1 11  +  5   +   8   +   11Your computer player/dealer would have to know which one the human player wanted to play.
Plus the computer would have to know which values the dealer wanted to play/use.

We know 100% what is in a deck of cards, so making each card final could work. I'm not sure if it would better to load the collection using a loop or hard coding them.
Loops can be quick to code, but you know exactly what is in the deck so hard coding them could result in a micro/nano second or two when compiling and/or executing the program.

As for as user actions/input I'm leaning toward something kind of like:
At first start up "Please provide your name [Player]: ____"
During the game actions like [H]it, [S]tand, [R]aise, [F]old, [B]et etc.

After the initial deal and after each subsequent card is dealt the player will have their standard actions that they can do.
Each user action is a behavior which may use an interface to change any system state value like increasing the money bet.

[Steven Mcdonald]

Pete Letkeman wrote:Steven, enums are implicitly final and most IDEs will suggest that you remove the final keyword if used with an enum.

Thank you for the tip, I didn't realize that.

Pete Letkeman wrote:With regards to Collections.shuffle(), this will probably work.

There are also other ways listed on StackExchange and GeeksForGeeks that might be a little but faster if speed becomes an issue, like the Fisher-Yates shuffle algorithm.

Pete Letkeman wrote:However along with that you should really look into implementing and overriding the equals(), hashCode() and toString() methods in your classes.

I haven't overridden any classes. Should I do this? I've already made all the custom classes and interfaces I think I might need, along with a couple extras like my Seat class for future multiplayer use and to randomly assign bots/the player to a seat for the single player game.

Pete Letkeman wrote:Would the player sort their cards? I know that I sort my cards in nearly every card game I play. So giving the user that option may not be a bad idea.

I hadn't thought of that, it sounds like a really good idea. All of my cards have an

int value

variable derived from their

.ordinal()

value in the enum and an if then else statement, which also sets a few other values like booleans and Strings for future use in a GUI.
This could be used to loop through and sort the cards. I haven't seen a Blackjack app so that yet.  

Pete Letkeman wrote:By the way, I do not know if you pick up on this yet or not, but the Ace can have either a value of 1 or a value of 11.

I planed on using my

.isAce()

and

.isBusted()

methods to change the value form 11 to 1 in the main code where my game logic will be located. This way the ace is only considered 1 if the total value is over 21, and code can be reused.
I have it separated so that I can also use the soft 17 rule for the dealer as well. Should I implement the value change in the card itself instead of the main code?

Pete Letkeman wrote:We know 100% what is in a deck of cards, so making each card final could work. I'm not sure if it would better to load the collection using a loop or hard coding them.
Loops can be quick to code, but you know exactly what is in the deck so hard coding them could result in a micro/nano second or two when compiling and/or executing the program.

A loop will take longer than a hard coded List, but I wanted to leave it open so it is quick to change from having one deck, to five decks, to eight, etc. I made a nested loop in the constructor to load each card into the deck List in mine but it's O(n3) time because of it.
It still goes fast when calling

Deck deck = new Deck();

in my main though.

Pete Letkeman wrote:During the game actions like [H]it, [S]tand, [R]aise, [F]old, [B]et etc.

I was going to try for wasd or 1234 and switch out options based on

.isStartRound()

for betting, and then do hit, stand, double, split after the betting is done. With a method for hitting Y/N for insurance against a blackjack.
This way there aren't too many buttons, and it still follows the core Blackjack rules I looked up on a Vegas site.

Pete Letkeman wrote:Each user action is a behavior which may use an interface to change any system state value like increasing the money bet.

Are you putting the main game logic somewhere other than the entry point for the program? I was thinking of putting the logic for the game inside a loop in public static void main, and passing to methods in the main class for certain parts of the game;
one for betting before round, one for each players turn, etc. Should I do this differently?

[Steven Mcdonald]

Sorry about the bright post, I misspelled quote at the top and of course it was one of the only times in my life that I haven't double checked a post before submitting. I looked it up and I guess I need cows? to edit the post.

[Pete Letkeman]

Steven Mcdonald wrote:Sorry about the bright post, I misspelled quote at the top and of course it was one of the only times in my life that I haven't double checked a post before submitting. I looked it up and I guess I need cows? to edit the post.

Fixed.

Enums are effectively final because you cannot subclass them or change their values. If you need that functionality then you will need a class or interface.

Steven Mcdonald wrote:I haven't overridden any classes. Should I do this?

Yes and no it all depends on the reasons for doing such an operation.
The @Override may not be needed, but it does help when compiling. This makes sure that you are dealing with the correct method(s). You can read more about this here.
Aside from that, yes you should defiantly create create equals(), hashCode() and toString() methods for your classes.
A lot of the times you are going to need to compare two different objects of the same class plus it's helpful to be able to see a practical representation of your class.

I do realize that you do have other questions Steven, I hoping that other members can help out with them. I have not completed creating my code yet even thought I'm stubbing some of the methods.
It's this whole 8 am to 6 pm job that seems to be getting if the way of this project.

[Stephan van Hulst]

Steven, Pete, if you guys PM me your GitHub usernames I will add you to the project where you're free to create your own branches (and work on existing ones).

[Knute Snortum]

A basic question about the GitHub account: are we trying to create one project that we all work on, or different projects in different branches?  I hope it's the former, and if so, I will wait until Pete has posted the base code to work on.

[Steven Mcdonald]

Knute Snortum wrote:A basic question about the GitHub account: are we trying to create one project that we all work on, or different projects in different branches?  I hope it's the former, and if so, I will wait until Pete has posted the base code to work on.

Hi Knute,
Your welcome to help with mine if you want, it would be great to get some help from more experienced people. The link to the repository is here, be forewarned though I'm a bit new to this so it's a bit of a mess. Also, not all of the game logic is completed, I still need to make a couple more classes for the bots and dealer decision trees, and most of the classes are doubled up, as I plan on using the interfaces as a platform for the JavaFX version once the text one is finished.

Pete,
I'll definitely check out using @override on some of the methods. I've used it for run in threads and runnables a couple of times a while back, but I wasn't sure if it was a good idea to use it for any other classes. Thank you for the help with the edit, and the advise.

[Stephan van Hulst]

One project for us all, with different branches for different features. This means that if one of the members wants to start working on the user interface or whatever, they can just start a branch and later merge that into the main branch of the project.

I already created a branch containing a Maven project layout with an example class and a unit test: https://github.com/CoderanchCorral/Blackjack/tree/features/core-model

I had intended for members to push their code to that branch. I am waiting for somebody to update the code so that the unit tests succeed, so we can merge an initial version of the project to the master branch.

[Stephan van Hulst]

Also, Knute, I want to ask you to approve the code in this pull request: https://github.com/CoderanchCorral/Blackjack/pull/1

I want to test that your approval gets dismissed when I push a new commit.

[Knute Snortum]

It looks like that pull request has been closed now.

[Stephan van Hulst]

Yes, Adrian approved the pull request, and then I pushed a new commit. It successfully dismissed Adrian's approval, so I found out what I wanted. I closed the pull request and deleted the branch.

[Stephan van Hulst]

Steven has another pull request open. I reviewed it and added some commits of my own. I suggest we merge it to master once it's been approved, so that everyone has a stable branch to work off of.

[Pete Letkeman]

Build tools can be your friend, there is brief posting regarding this here https://coderanch.com/t/699669/open-source/Maven-Gradle-Ant

[Pete Letkeman]

You really need to become familiar with unit testing.
People using Test Driven Design (TDD) and Behavior Drive Design (BDD) and unit testing in general with many projects in many different programming languages and environments.
Some projects/companies expect unit tests with every commit which cover a certain percentage of code.
There is a posting about there found here https://coderanch.com/t/699671/open-source/Unit-testing

[Adrian Grabowski]

Ok, I finally found some time to catch up, made couple of small commits to Steven's branch and it looks like I haven't broken anything yet ;)

I found one problem, I tried to set up my IDE so the coding style would match the existing one but managed to mess it up instead, is there a way we could set it up so all our IDEs would understand it? Some kind of configuration file?

[Knute Snortum]

I think this is the purpose of EditConfig, though I haven't used it.  In IDEs like Eclipse and IntelliJ you have an extensive formatting configuration area.  Then with a few keystrokes (Ctrl-Shift-F in Eclipse) you have formatted code.  One of the challenges of writing code with other people is agreeing on a style and making changes in that style, so this is good practice.  

[Liutauras Vilda]

I couldn’t say I like current 2-spaces indent level (I’d personally prefer 4), but I much more like an idea that I stick to team’s convention and everything is consistent.

[Stephan van Hulst]

Personally I like 2 spaces, but I've noticed it's less clear to see the indentation level on GitHub, so I'm fine with changing it to 4 spaces. I will do this after Steven's branch has been merged into the core-model branch, because I want to combine this with a rebase on master.

[Pete Letkeman]

Aside from two or four spacing there are many other style options and opinions. Google has shared style guides with the public which can be found at https://github.com/google/styleguide.
There is a style guide file for Java for Eclipse and a style guide file for Java for IntelliJ. Other IDEs may be able to import and use either the Eclipse or IntelliJ files.
At work they use the Google Java style guide, which does mean two spaces and not four. However I could go with a different style guide as long as it is clearly defined.

The Google Java Style Guide may have different values for style then the official CodeRanch Style Guide https://javaranch.com/style.jsp.
The Google guides may have different values then Sonar or other code quality analysis tools.

Yes, my initial thought was to use the dot editor config to help with style and it may still be able to. However I think that an style XML file may be a better way to go.
The other point about the editor config was regarding plugins and how they may help you out.

[Steven Mcdonald]

Adrian Grabowski wrote:Ok, I finally found some time to catch up, made couple of small commits to Steven's branch and it looks like I haven't broken anything yet ;)

Hi Adrian, I redid the entire repository in my personal GitHub and it's completed, if you want to check that out for a reference. I'm not sure what everyone's coding level is at, but I'm new so all of the code is fairly basic/ commonly used core classes. It may help newer people like myself understand the basic structure for text based BlackJack, as a "crude sketch" of what we are doing collectively. I know personally I'm learning a lot more from the CodeRanch Version after just a couple classes, than I did writing the program by myself.

[Steven Mcdonald]

Hi all,
I was just wondering what to do in the corral project. I'm not sure if we're just supposed to start adding new classes in a pull? Are there certain classes we're doing first?

[Pete Letkeman]

First I would make sure that everything posted runs as expected.
Next I would make sure that the unit tests are there, and if not then I'd add them.

Now  that you have a copy of the project and all of the required unit test fire as expected you should try to see what is missing.
For instance, is there a method which draws a card? If not you could add one.
However if there is one, how does it do it? Does it use AWT, JavaFX, Swing, ASCII, etc?
Ideally the project should support a render card interface and there should be more then one implementation of it.

You can add what ever classes you want, but note that your code will be inspected and people may have questions/comments about your changes.
There may be a changelog and a backlog, but then again those may not be there yet.

Another thing you could do it go over the code to see if it make sense to you.
If you have any questions regarding the code start a thread in the Corral and hopefully some people will join in and discuss them.