On 8/3/2014 1:25 PM, Jeff Higgins wrote:
On 08/03/2014 11:41 AM, Eric Sosman wrote:
On 8/3/2014 11:08 AM, Jeff Higgins wrote:
On 08/01/2014 09:16 PM, Scott Dunning wrote:
Hello, I have an assignment for my summer class. FYI, I'm super
new to
programming in general and this is my first time with java and it's a
summer class so it's going super fast (please be nice!) lol.
No. It seems to be going slowly. The last three assignments you've
brought here are rehashes. Surely by now you should have gone into
interfaces and collections.
Your Card class will be more easily used if it implement the
java.lang.Comparable<T> interface
I'd advise against this,
because the ordering depends not on the
Card, but on the rules of whatever game is being played.
Exactly.
There are
games where Ace is high, games where it is low, games where it can
be either at the discretion of the player, and for all I know there
may be games where Ace can lie between King and Deuce. And then
there's the question of suit: How does the Seven of Hearts compare
to the Jack of Clubs? Would knowing whether Hearts are trumps affect
your answer?
Scott: Don't Go There; you'll just get lost.
Scott: If you don't go there you'll never find your way.
package scratch;
/**
* The face value of a {@link Card}.
*
* Rank specifies one of 13 distinct,
* implementation defined values and their order.
"Poker" is the name for a popular family of card games in which
this approach Absolutely Will Not Work. I've already mentioned that
Ace can be lower than Deuce, Deuce lower than Trey, ..., Queen lower
than King, and King lower than (oops!) Ace. The "total ordering"
required by Comparable simply doesn't exist, and any attempt to
implement Comparable is just plain doomed.
It gets worse: There are situations where Ace compares unequal
to Ace, that is, where one Ace compares lower/higher than another,
as in A 2 3 4 5 (the lowest possible straight) vs. T J Q K A (the
highest possible). The result of `ACE.compareTo(ACE)' could be
negative, zero, or positive depending on the situation -- and the
compareTo() method doesn't have access to situational information.
But wait! That's not all; it gets even worse still! There are
situations where the very same instance of an Ace is both high and
low at the same time! Ordinary poker variants award the entire pot
to the highest-ranking hand, but "high-low" variants divide it between
the highest and the lowest hand. If you hold A 2 3 4 5 you have a
chance of being both the lowest *and* the highest: Call the Ace low
and you've got a straight (not a rock-crusher, but a fairly good hand),
or call it high and have a bust with one high card (not the worst
possible hand, but pretty weak). In this situation the very same
instance of Ace is both higher *and* lower than Deuce, both higher
*and* lower than itself! And you want to capture this in Comparable?
Given the variety of card games, Comparable is a wrong-headed
approach for ranks, for suits, and even for hands.
Scott: Don't Go There; you'll just get lost.
Comparable<> is not the one and only ordering. Comparable<> is
just the natural ordering. It is perfectly valid to have a