Re: proper use of .java files (layout)
markspace wrote:
Lew wrote:
markspace wrote:
public class PlayingCard {
private final int value; // Ace = 1
I would make this an enum.
"Ace = 1" is not a valid association in the problem domain, and its use
as a representation creates risk of an artificial equivalency.
I was actually thinking about that. I don't like the idea of trying to
encode most of the values of a face card as enums. Something like this
might be a reasonable compromise.
I wouldn't code *any* of the values of the face cards or the pip cards as anything
in the PlayingCard type.
public static enum Cards {ACE, DEUCE, KING, QUEEN, JACK
, TEN, NINE, EIGHT, SEVEN, SIX, FIVE, FOUR, TREY, JOKER,
}
And I'd put them in order {JOKER, ACE, DEUCE, ..., }
public void set( Cards card, Suit suit ) {
'Card', not 'Cards'.
switch( card ) {
case ACE: value = 1; break;
That's clumsy. But how will this work for Blackjack?
case DEUCE: value = 2; break;
case KING: value = 13; break;
case QUEEN: value = 12; break;
case JACK: value = 11; break;
}
this.suit = suit;
}
public void set( int card, Suit suit ) {
value = card;
Should not be an 'int', I reiterate.
There is nothing "integery" about the card name.
this.suit = suit;
}
I also think it might be valuable to have one implementation of
PlayingCard with one internal encoding, then assigning different
Yes, the "internal encoding" is the enum constant.
semantics (e.g., ace high or low) in a separate game object. Trying to
That.
overload PlayingCard too much with too much business logic seems to
Agreed.
violate encapsulation. A simple wrapper class could easily switch the
Not "switch", assign, and not a "simple wrapper class" but a games rule engine.
value of an ace; so could a custom comparator. Without more
requirements from the OP, it's really hard to guess what of the many
possible solutions is best.
I was going for modeling a playing card so it would work in any card game.
So I went with a simple
but feckless
implementation of "ace" (ace = 1) and I'm
leaving to other logic to decide how to treat that. You could have
other more complicated implementations of PlayingCard, but too much gets
You've already included too much by having an 'int' value.
too baroque quickly
^H^H^H^H^H^H^Halready
, imo, especially if you don't need all that
functionality for most use cases.
You don't need the 'int' value for any use cases.
Another example: in many standard decks, the names of the suits are not
Spades, Hearts, etc. but vary by country. Again I'm leaving that for
Silliness. We know from the OP's problem statement that they intend the French suits.
some other part of the program. Localization of card names can be done
by wrapping this PlayingCard with a GermanPlayingCard, for example.
Wrap, wrap, wrap. You sure are addicted to wrapping. I wouldn't recommend that.
How would a 'GermanPlayingCard' delegate to the standard French model?
I'd use a different type that implements a suitable interface, or just use a different enum.
But I can't really see the refactoring clearly from here. I'd need a candidate implementation
to refactor.
--
Lew