Monday, 12 December 2011

Java: Texas Hold Em (19)

Hey hey, post as promised, late as promised! I'm so awesome! Today we're continuing with our HandValue class, and we'll be done with it tonight! I do hope after all this time wasted this project doesn't end up being a flop :P

After this, we could move on to the Table, but that is what Players sit at, so we should do those. However, it looks like the Player class needs a Client interface to work with. Being an interface, and not a class, if you remember, this means that Client will be a collection of related methods, but empty.

We`re starting to get into territory that I don`t quite get, so...good luck? We'll see how this pans out!


So looking back on our blueprint, the easiest stuff to pull off would be the standard get...() methods, one for each of: Hand, Type, Description and Value, so let's get them outta the way:

Well, that's 15 lines of simplicity, I shouldn't need to explain any of it! Next, and to finish up, we have the 2 comparison methods (equals and compareTo) as well as the toString methods. Note that there should probably be (as your IDE might tell you) an "@Override" on the line above each method declaration.
This is because these methods exist by default, and it could cause some trouble if a program uses the wrong one. I left them out just for screenshot space, but it is not a good idea for functionality!!

Okay, something to go through! First, we have equality to check for, and that's simple enough.
Line 44 makes sure the parameter, obj (what we're comparing this current object to) is actually a HandValue. The instanceof keyword tests if something is of the same type as what you specify.
This is pretty cool, it's what stops you performing equals() on a String and an Integer, for instance!
Line 45 is the actually testing step, grabbing the (converted to HandValue, just in case) integer value for both objects and comparing them directly, as integers!

None of the rest of that bears explanation! So let's go to the compareTo method:
Line 52-53: Using the same general idea as .equals(), we're comparing the int values to each other. If the compared object is lower, return -1, the negative number symbolizing the compared value is lower.
Lines 54-55: Same deal, but with the compared value being higher, in which case a positive number, 1, is returned!
Lines 56-57: Neither of the above being true means the hands are equal, so a 0 is returned, symbolizing equality.

Finally, we have a toString method, allowing us to System.out.print our HandValue. I didn't bother changing the code, though I probably would have written:

return type.getDescription() + "(" + value + ")";


Still, it works. String formatting is easier to work with, technically, but being a simple man, I prefer my inefficiency! I'll show ya'll how to use string formatting on my weekend posts this week, I guess!


Anyway, that's it, done, no more HandValue to worry about, we can now move onto our Client interface, then we'll pull off the Player, ConsoleClient and Table classes. After that, I think we'll be good to move onto the GUI? We'll see! And I'll see! You, tomorrow! Need more exclamation marks! Questions and comments welcome!

3 comments:

  1. Oh wow, this is getting pretty intense, it's good to get the HandValue out of the way. Don't give up!

    ReplyDelete
  2. Late as promised? Great! Thanks! As for the Client being empty that just sounds sad! Thinking of that souless client at the table!

    ReplyDelete