proper use of .java files (layout)

Discussion in 'Java' started by infinitum3d@hotmail.com, Dec 16, 2012.

  1. Guest

    I'm trying to figure out the best way to layout a java program. Should I put each object into its own .java file? If I'm making a card game, that would be 52 .java files. Is that crazy? Normal?

    Or should I separate them by suit and just have 4 .java files? Or by value so there are 13 .java files?

    Thanks!

    I3D
     
    , Dec 16, 2012
    #1
    1. Advertising

  2. On 16.12.2012 16:38, wrote:
    > I'm trying to figure out the best way to layout a java program.
    > Should I put each object into its own .java file? If I'm making a
    > card game, that would be 52 .java files. Is that crazy? Normal?


    Crazy.

    > Or should I separate them by suit and just have 4 .java files? Or by
    > value so there are 13 .java files?


    You better had just one class for Card which has different properties.
    Which properties you need depends of course on the card at hand and on
    the application. Sometimes it may make sense to make Card an interface
    and have different implementing classes. But that all depends on the
    application that is being written.

    Kind regards

    robert


    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Dec 16, 2012
    #2
    1. Advertising

  3. Arne Vajhøj Guest

    On 12/16/2012 10:38 AM, wrote:
    > I'm trying to figure out the best way to layout a java program.
    > Should I put each object into its own .java file? If I'm making a
    > card game, that would be 52 .java files. Is that crazy? Normal?
    >
    > Or should I separate them by suit and just have 4 .java files? Or by
    > value so there are 13 .java files?


    You need to distinguish between classes and objects.

    You will have one class per Java file (actually you can
    have more than one, but let us keep this simple to start with).

    When the program runs then you can create one or more instances
    of that class - those instances are objects.

    A deck of card will usually be considered 52 instances/objects
    of 1 class.

    Arne
     
    Arne Vajhøj, Dec 16, 2012
    #3
  4. markspace Guest

    On 12/16/2012 7:38 AM, wrote:
    > I'm trying to figure out the best way to layout a java program.
    > Should I put each object into its own .java file? If I'm making a
    > card game, that would be 52 .java files. Is that crazy? Normal?


    What Arne and Robert said. In this case you want a single class with
    two fields, one for suit and one for face value. (You could encode both
    the suit and the value in to a single field. However this sort of space
    saving is usually counter-productive, unless you're absolutely sure it's
    needed.)

    public class PlayingCard {
    private final int value; // Ace = 1
    private final Suit suit;

    public static enum Suit { HEARTS, CLUBS, SPADES, DIAMONDS }

    ... ect....

    }


    You will of course have to make 52 instances of that class. Do that at
    runtime, don't try to make 52 files.
     
    markspace, Dec 16, 2012
    #4
  5. Guest

    Brilliant! That makes perfect sense.

    Thank you all for the advice. This will really make things easier for me.

    -I3D
     
    , Dec 16, 2012
    #5
  6. In article <50cdede4$0$291$>,
    Arne Vajhøj <> wrote:

    > On 12/16/2012 10:38 AM, wrote:
    > > I'm trying to figure out the best way to layout a java program.
    > > Should I put each object into its own .java file? If I'm making a
    > > card game, that would be 52 .java files. Is that crazy? Normal?
    > >
    > > Or should I separate them by suit and just have 4 .java files? Or
    > > by value so there are 13 .java files?

    >
    > You need to distinguish between classes and objects.
    >
    > You will have one class per Java file (actually you can have more
    > than one, but let us keep this simple to start with).
    >
    > When the program runs then you can create one or more instances of
    > that class - those instances are objects.
    >
    > A deck of card will usually be considered 52 instances/objects of 1
    > class.


    infinitum3d: There's a nice example that illustrates this using typesafe
    enums, introduced in Java 1.5:

    <http://docs.oracle.com/javase/1.5.0/docs/guide/language/enums.html>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
     
    John B. Matthews, Dec 16, 2012
    #6
  7. Guest

    Thank you John. I'll look into it :)

    I3D
     
    , Dec 17, 2012
    #7
  8. Lew Guest

    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.

    > private final Suit suit;


    That's more like it.

    > public static enum Suit { HEARTS, CLUBS, SPADES, DIAMONDS }
    > ... ect.... [sic]
    > }
    >
    > You will of course have to make 52 instances of that class. Do that at


    No "of course" about it.
    http://www.hoylegaming.com/rules/showrule.aspx?RuleID=209

    > runtime, don't try to make 52 files.


    How many cards in a blackjack shoe?
    http://en.wikipedia.org/wiki/Blackjack

    If you hard-code certain assumptions, e.g., that there are 52 cards in the deck,
    your program will be unable to model many games.

    --
    Lew
     
    Lew, Dec 17, 2012
    #8
  9. markspace Guest

    On 12/17/2012 10:28 AM, 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.

    public static enum Cards {ACE, DEUCE, KING, QUEEN, JACK }

    public void set( Cards card, Suit suit ) {
    switch( card ) {
    case ACE: value = 1; break;
    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;
    this.suit = suit;
    }

    I also think it might be valuable to have one implementation of
    PlayingCard with one internal encoding, then assigning different
    semantics (e.g., ace high or low) in a separate game object. Trying to
    overload PlayingCard too much with too much business logic seems to
    violate encapsulation. A simple wrapper class could easily switch the
    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.

    So I went with a simple 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
    too baroque quickly, imo, especially if you don't need all that
    functionality for most 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
    some other part of the program. Localization of card names can be done
    by wrapping this PlayingCard with a GermanPlayingCard, for example.
     
    markspace, Dec 17, 2012
    #9
  10. Lew Guest

    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
     
    Lew, Dec 17, 2012
    #10
  11. Arne Vajhøj Guest

    On 12/17/2012 4:17 PM, markspace wrote:
    > On 12/17/2012 10:28 AM, 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.


    Why not?

    13 distinct values with an order but no numeric values
    seems a perfect fit for enum to me.

    > 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
    > some other part of the program. Localization of card names can be done
    > by wrapping this PlayingCard with a GermanPlayingCard, for example.


    Or by using standard I18N techniques in the UI layer!

    Arne
     
    Arne Vajhøj, Dec 18, 2012
    #11
  12. Arne Vajhøj Guest

    On 12/17/2012 1:28 PM, Lew wrote:
    > markspace wrote:
    >> You will of course have to make 52 instances of that class. Do that at

    >
    > No "of course" about it.
    > http://www.hoylegaming.com/rules/showrule.aspx?RuleID=209
    >
    >> runtime, don't try to make 52 files.

    >
    > How many cards in a blackjack shoe?
    > http://en.wikipedia.org/wiki/Blackjack
    >
    > If you hard-code certain assumptions, e.g., that there are 52 cards in the deck,
    > your program will be unable to model many games.


    I would argue that a deck is always 52 cards, but that some
    games use more than one deck.

    Arne
     
    Arne Vajhøj, Dec 18, 2012
    #12
  13. Arne Vajhøj Guest

    On 12/17/2012 5:32 AM, lipska the kat wrote:
    > Here is a possible outline for a simple card game component
    > It has NOT been compiled.


    And it will not.

    .... is not valid Java (in the context where it is used).

    > Comments welcome
    >
    > Card.java
    >
    > public class Card{
    > //enumeration types for rank and suit perhaps
    > ...
    > }
    >
    > ==========================
    >
    > Deck.java
    >
    > public class Deck{
    >
    > private Card[] deck = null; //implementation hidden from clients
    >
    > public Deck(Integer cardCount){
    > deck = new Card[cardCount]; //not all games use all the cards
    > }
    > ...
    > }
    >
    > =========================
    >
    > Dealer.java
    >
    > public class Dealer{
    >
    > private Deck deck = null;
    >
    > public Dealer(Deck deck){
    > this.deck = deck;
    > }
    >
    > public void shuffle(){
    > ... //delegate to deck ?
    > }
    > ...
    >
    > public List<Card[]> deal(Integer hands, Integer cardsPerHand){
    > ...
    > }
    > }
    >
    > ===========================
    >
    > Snap.java
    >
    > public class Snap {
    >
    > private Deck deck = null;
    > private Dealer dealer = null;
    >
    > public Snap(){
    > this.deck = new Deck(54); // don't forget the jokers
    > this.dealer = new Dealer(deck);
    > }
    >
    > public void play(Integer numPlayers){
    > dealer.shuffle();
    > dealer.deal(numPlayers, 0); // 0 indicates deal all to players
    > ...
    > }
    > ...
    > }
    >
    > Java is well suited to an 'Object Oriented' approach to software design
    > The above outline is just one of many possible OO solutions.



    A Deck constructor with just the number of jokers would make
    more sense to me.

    The Deck(cardCount) does not specify what cards are there. And
    it is not really a deck but a deck with something added or
    removed.

    Arne
     
    Arne Vajhøj, Dec 18, 2012
    #13
  14. On Mon, 17 Dec 2012 20:55:21 -0500, Arne Vajhøj <>
    wrote:

    [snip]

    >13 distinct values with an order but no numeric values
    >seems a perfect fit for enum to me.


    An enum does not guarantee an order.

    Do you play poker? Aces are usually high, but can be low in the
    case of straights.

    [snip]

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Dec 18, 2012
    #14
  15. On Mon, 17 Dec 2012 20:58:59 -0500, Arne Vajhøj <>
    wrote:

    >On 12/17/2012 1:28 PM, Lew wrote:


    [snip]

    >> If you hard-code certain assumptions, e.g., that there are 52 cards in the deck,
    >> your program will be unable to model many games.

    >
    >I would argue that a deck is always 52 cards, but that some
    >games use more than one deck.


    Some games do not use all of the deck; some include one or more
    jokers. See the section "Modified Deck" in
    http://boardgamegeek.com/wiki/page/Standard_Deck_Playing_Card_Games
    for several examples.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Dec 18, 2012
    #15
  16. Eric Sosman Guest

    On 12/17/2012 8:58 PM, Arne Vajhøj wrote:
    > On 12/17/2012 1:28 PM, Lew wrote:
    >> markspace wrote:
    >>> You will of course have to make 52 instances of that class. Do that at

    >>
    >> No "of course" about it.
    >> http://www.hoylegaming.com/rules/showrule.aspx?RuleID=209
    >>
    >>> runtime, don't try to make 52 files.

    >>
    >> How many cards in a blackjack shoe?
    >> http://en.wikipedia.org/wiki/Blackjack
    >>
    >> If you hard-code certain assumptions, e.g., that there are 52 cards in
    >> the deck,
    >> your program will be unable to model many games.

    >
    > I would argue that a deck is always 52 cards, but that some
    > games use more than one deck.


    How come a brand-new pack of cards always has fifty-four?

    --
    Eric Sosman
    d
     
    Eric Sosman, Dec 18, 2012
    #16
  17. Arne Vajhøj Guest

    On 12/17/2012 9:18 PM, Gene Wirchenko wrote:
    > On Mon, 17 Dec 2012 20:55:21 -0500, Arne Vajhøj <>
    > wrote:
    >
    > [snip]
    >
    >> 13 distinct values with an order but no numeric values
    >> seems a perfect fit for enum to me.

    >
    > An enum does not guarantee an order.


    In the Java I use enums have a compareTo method.

    Arne
     
    Arne Vajhøj, Dec 18, 2012
    #17
  18. Arne Vajhøj Guest

    On 12/17/2012 9:25 PM, Eric Sosman wrote:
    > On 12/17/2012 8:58 PM, Arne Vajhøj wrote:
    >> On 12/17/2012 1:28 PM, Lew wrote:
    >>> markspace wrote:
    >>>> You will of course have to make 52 instances of that class. Do that at
    >>>
    >>> No "of course" about it.
    >>> http://www.hoylegaming.com/rules/showrule.aspx?RuleID=209
    >>>
    >>>> runtime, don't try to make 52 files.
    >>>
    >>> How many cards in a blackjack shoe?
    >>> http://en.wikipedia.org/wiki/Blackjack
    >>>
    >>> If you hard-code certain assumptions, e.g., that there are 52 cards in
    >>> the deck,
    >>> your program will be unable to model many games.

    >>
    >> I would argue that a deck is always 52 cards, but that some
    >> games use more than one deck.

    >
    > How come a brand-new pack of cards always has fifty-four?


    It does not always.

    It comes with 2, 3 or maybe even 4 jokers.

    So number of jokers should be a constructor argument, if
    it has to be realistic.

    Arne
     
    Arne Vajhøj, Dec 18, 2012
    #18
  19. Eric Sosman Guest

    On 12/17/2012 9:29 PM, Arne Vajhøj wrote:
    > On 12/17/2012 9:25 PM, Eric Sosman wrote:
    >> On 12/17/2012 8:58 PM, Arne Vajhøj wrote:
    >>>
    >>> I would argue that a deck is always 52 cards, but that some
    >>> games use more than one deck.

    >>
    >> How come a brand-new pack of cards always has fifty-four?

    >
    > It does not always.
    >
    > It comes with 2, 3 or maybe even 4 jokers.
    >
    > So number of jokers should be a constructor argument, if
    > it has to be realistic.


    Can we say, then, that "a deck is always 52 cards, for
    suitable values of 52?"

    --
    Eric Sosman
    d
     
    Eric Sosman, Dec 18, 2012
    #19
  20. Arne Vajhøj Guest

    On 12/17/2012 9:32 PM, Eric Sosman wrote:
    > On 12/17/2012 9:29 PM, Arne Vajhøj wrote:
    >> On 12/17/2012 9:25 PM, Eric Sosman wrote:
    >>> On 12/17/2012 8:58 PM, Arne Vajhøj wrote:
    >>>>
    >>>> I would argue that a deck is always 52 cards, but that some
    >>>> games use more than one deck.
    >>>
    >>> How come a brand-new pack of cards always has fifty-four?

    >>
    >> It does not always.
    >>
    >> It comes with 2, 3 or maybe even 4 jokers.
    >>
    >> So number of jokers should be a constructor argument, if
    >> it has to be realistic.

    >
    > Can we say, then, that "a deck is always 52 cards, for
    > suitable values of 52?"


    Very funny.

    A deck is 52 + number of jokers cards.

    A game may be multiple decks or maybe even a subset of a deck.

    Arne
     
    Arne Vajhøj, Dec 18, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick Spiewak
    Replies:
    3
    Views:
    3,179
    Rick Spiewak
    Aug 26, 2003
  2. RobertH
    Replies:
    1
    Views:
    738
    Steve C. Orr [MVP, MCSD]
    Nov 4, 2003
  3. NWx
    Replies:
    4
    Views:
    2,983
    Kevin Spencer
    Feb 19, 2004
  4. Replies:
    1
    Views:
    604
    John Timney \(MVP\)
    Jun 19, 2006
  5. H. Wade Minter
    Replies:
    8
    Views:
    309
    Robin
    Apr 25, 2004
Loading...

Share This Page