Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > proper use of .java files (layout)

Reply
Thread Tools

proper use of .java files (layout)

 
 
infinitum3d@hotmail.com
Guest
Posts: n/a
 
      12-16-2012
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
 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      12-16-2012
On 16.12.2012 16:38, http://www.velocityreviews.com/forums/(E-Mail Removed) 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/
 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      12-16-2012
On 12/16/2012 10:38 AM, (E-Mail Removed) 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
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      12-16-2012
On 12/16/2012 7:38 AM, (E-Mail Removed) 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.


 
Reply With Quote
 
infinitum3d@hotmail.com
Guest
Posts: n/a
 
      12-16-2012
Brilliant! That makes perfect sense.

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

-I3D
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      12-16-2012
In article <50cdede4$0$291$(E-Mail Removed)>,
Arne Vajhøj <(E-Mail Removed)> wrote:

> On 12/16/2012 10:38 AM, (E-Mail Removed) 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>
 
Reply With Quote
 
infinitum3d@hotmail.com
Guest
Posts: n/a
 
      12-17-2012
Thank you John. I'll look into it

I3D

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-17-2012
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/sho...spx?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
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      12-17-2012
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.

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-17-2012
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What's the proper way to use SocketChannel.finishConnect()? - Java 1 07-26-2005 01:03 AM
Proper use of assertions Razvan Java 5 10-08-2004 02:39 PM
Proper way to use an imported constant under 'use strict'? H. Wade Minter Perl Misc 8 04-25-2004 12:58 AM
Proper (vs. desirable) use of Graphics object Wolfgang Java 7 01-23-2004 05:42 PM
Proper use of CharsetDecoder? Harald Kirsch Java 1 08-05-2003 07:15 PM



Advertisments