Project 4
¿Cuál es mejor?


In this project, you will continue with modeling the game of poker. Just as in the previous project, you will be using community cards and hole cards. From the user's perspective, the program will play exactly the same game as played by the previous project.

The main changes from the last project are:

  1. Your code be in Java instead of Python. It will still be object-oriented, but will conform to the Java syntax and conventions and use Java libraries to get the job done.
  2. We will introduce a way to more efficiently model a deck of cards. This will involve a change of internal representation of a deck, but we'll use information hiding to isolate this change from the rest of the code.


Part I: Coding and Testing

Make a testing habit

You should really get in the habit of testing as you go. Write a bit, test a bit goes a whole lot better than Write a bunch, tear out hair because it doesn't work.

Toward that end, if you haven't done so already, you MUST test as you go in this project, and you must keep the tests so I can see them.

Write test code

Create a PokerComparisonTests class in This class should have a main method (public static void main(String[] args)) that calls other static methods, each of which tests some scenario for comparing two poker hands. For example, you might have a testBothFlush method that tests compareTo with two hands that have flushes.

You don't need to write all the tests at once, but as you write code in your poker hand class, add some code here that will test it. Get in the habit of testing every method you write.

Don't erase or comment out tests. Once you have some code that works and is tested, don't throw away the tests. Keep it so you can always re-run it if you change something.

Translate to Java

Your primary job is to re-write your program in Java. You must:

Required classes/methods

You must have the following classes:

A Note on Reusability

In the previous project, you might have had methods in your PokerHand, StudPokerHand, and CommunityCardSet that dealt with Deck objects. Perhaps your PokerHand's method to add a card would only add cards drawn from a deck you passed? Maybe your PokerHand constructor dealt 5 cards from a deck?

You probably discovered that this made some things harder that necessary. For example, when you went to create all 5-card hands that can be made from 7 cards, you needed a way to construct PokerHands that didn't draw cards from a deck. And when you wanted to test your PokerHand compare_to method, you needed to be able to create specific hands, not just random hands drawn from a deck. In other words, your code wasn't very reusable. While in some situations it was convenient to deal from a deck, in other situations it was very inconvenient.

So, for this project, I am introducing an additional requirement: your PokerHand, StudPokerHand, and CommunityCardSet classes cannot use a Deck object. So, when you want to deal a card from a deck into a hand, you'll call Deck's deal method and pass the resulting Card to your hand's addCard method.

Part II: A representation change

Once the code works, it's time to make it more efficient. One place where improvement is possible is in the Deck.

Your first version of the Deck class probably has the following internal representation:

This internal representation is simple and easy to implement, but can be inefficient. Depending on how it's implemented, removing from a list can take linear time, so dealing a card is a linear operation. We'll address this inefficiency by changing our internal representation for a Deck. Now we'll use 2 instance variables to represent a deck:

Re-write your Deck so that it uses this internal representation to make dealing a card efficient. What will deal need to do?

Turn it in

Turn in the project by compressing the project folder and emailing it to me. Be sure you have the honor code pledge written at the top of each java source file.

Please remember to name your project using your last name (like CassProject4) when you create it in IntelliJ.