X-Received: by 10.66.82.164 with SMTP id j4mr2758pay.15.1355781074109; Mon, 17 Dec 2012 13:51:14 -0800 (PST) Received: by 10.50.0.204 with SMTP id 12mr49628igg.9.1355781074066; Mon, 17 Dec 2012 13:51:14 -0800 (PST) Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nntp.club.cc.cmu.edu!newsfeed.news.ucla.edu!usenet.stanford.edu!kt20no9896715pbb.1!news-out.google.com!6ni50330pbd.1!nntp.google.com!kt20no9896712pbb.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.java.programmer Date: Mon, 17 Dec 2012 13:51:13 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T NNTP-Posting-Host: 69.28.149.29 References: <20fa5c05-6fcc-47ed-9e80-a44975887928@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <45eb8d50-e812-4d2e-b53b-b0d4da97d982@googlegroups.com> Subject: Re: proper use of .java files (layout) From: Lew Injection-Date: Mon, 17 Dec 2012 21:51:14 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: csiph.com comp.lang.java.programmer:20399 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