proper use of .java files (layout)

[infin...@hotmail.com]

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

[Robert Klemme]

On 16.12.2012 16:38, infin...@hotmail.com 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/

[Arne Vajhøj]

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

[markspace]

On 12/16/2012 7:38 AM, infin...@hotmail.com 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.

[infin...@hotmail.com]

Brilliant! That makes perfect sense.

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

-I3D

[John B. Matthews]

In article <50cdede4$0$291$1472...@news.sunsite.dk>,

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>

[infin...@hotmail.com]

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

I3D

[lipska the kat]

Here is a possible outline for a simple card game component
It has NOT been compiled.

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.

Hope this helps

lipska

--
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[Lew]

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

[markspace]

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.

[Lew]

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

[Arne Vajhøj]

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]

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]

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).

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

[Gene Wirchenko]

On Mon, 17 Dec 2012 20:55:21 -0500, Arne Vajhøj <ar...@vajhoej.dk>
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]

On Mon, 17 Dec 2012 20:58:59 -0500, Arne Vajhøj <ar...@vajhoej.dk>
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

[Eric Sosman]

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

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Arne Vajhøj]

On 12/17/2012 9:18 PM, Gene Wirchenko wrote:
> On Mon, 17 Dec 2012 20:55:21 -0500, Arne Vajhøj <ar...@vajhoej.dk>
> 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]

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

[Eric Sosman]

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

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Arne Vajhøj]

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]

Jokers has already been discussed.

I would not change the definition of deck because some
games does not use all cards in a deck.

public interface Game {
...
public List<Card> cardsUsed();
}

Arne

[Gene Wirchenko]

On Mon, 17 Dec 2012 21:28:07 -0500, Arne Vajhøj <ar...@vajhoej.dk>

wrote:

>On 12/17/2012 9:18 PM, Gene Wirchenko wrote:
>> On Mon, 17 Dec 2012 20:55:21 -0500, Arne Vajhøj <ar...@vajhoej.dk>
>> 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.

And how would you handle the aces?

A-6-4-3-2 is ace high, but A-5-4-3-2 is actually 5-4-3-2-A (a
five-high straight).

Human systems can be remarkably exceptional if I may use the word
in the sense of "having an exception".

Sincerely,

Gene Wirchenko

[lipska the kat]

On 18/12/12 02:03, Arne Vajhøj wrote:
> 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.

Really, well thank you for pointing that out

[snip]

>> 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.

Like I said, it was just an outline.

In my house we play games that use a subset of a complete deck,
sometimes we play a game that uses only the lower ranks of several packs
of cards

A Pack of cards contains 54 cards including two jokers.
a Deck of cards contains the cards required to play a game, not the same
thing at all ... hey look, we're already starting to come up with some
new classes, cool huh.

These type of questions/issues would come out in the wash. You need a
place to start, often the final result looks nothing like the first
iteration. Object Oriented software engineering is an iterative process.
More that that it is a state of mind.

[lipska the kat]

On 18/12/12 04:06, Stefan Ram wrote:

> markspace<-@.> writes:
>> 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.
>

> I do not like the idea of designing a card game /before/
> I know exactly /which/ card game it is at all. I need to
> know the rules of this card game and what exactly has to be
> programmed (e.g., human players or also computer [AI]
> players?). Only then I start to design.
>
> But often not even then do I do a beforehand OOD. Instead,
> I start out procedurally, using OOP only where it is obvious.
> Then I start to see OO patterns in the procedural code,
> so I then refactor into OOD and eventually arrive at an
> »object-oriented program«.

Then I suggest with respect that you do not 'get' OO.
The idea of designing computer systems as a series of communicating
abstractions of real world human concepts (Classes) came about exactly
because procedural programming was shown to be unsuitable for large
scale complex systems.

Starting out with a procedural design then trying to force it into an OO
model seems to be a lot of work to me. A better approach would be to
come up with a high level abstraction first, in this case 'CardGame'

Then we start to break the problem down, immediately we can split the
word into two classes, Card and Game, we have already halved the problem.

Now we take Card, in the real word we know that we don't play a game
with a single card, we know that a card is a member of a pack of 54,
another word pops out Pack ... this is a new class. We can now go away
and develop a Pack of Cards independently of our game ... and it will be
reusable to boot... THIS is OO

Notice that until now I know nothing about what game I might be
'designing' in fact I venture to suggest that we will discover, in the
end that a Game' is nothing more than a set of rules that we can apply
to our Deck. Our Deck is made up of a number of cards from one or more
(reusable) Packs. Our Game will use a reusable Dealer who has a shuffle
and deal methods. Once we have all these Classes in place we can start
thinking about the rules of the game. The detail comes at the end, not
at the beginning.

Just my POV

[Chris Uppal]

lipska the kat wrote:

> Notice that until now I know nothing about what game I might be
> 'designing' in fact I venture to suggest that we will discover, in the
> end that a Game' is nothing more than a set of rules that we can apply
> to our Deck. Our Deck is made up of a number of cards from one or more
> (reusable) Packs.

Just want to point out that your OO "modelling" here is making quite a few
asumptions about what kind of game we are going to want to play with the cards.
I'm not saying that's a bad thing, but it could /get/ bad if you were doing it
without being aware of it.

For instance:

Can cards be marked as part of the game ? (Legaloloy, I mean -- for
instance "cheating" might be allowed as part of the game)

If we have > 1 pack, are the two 2 of Hearts considered /identical/, or are
they distinguished in some way ? (Perhaps by the colours of the backs of the
cards).

Can new packs be added to the game as it is played ?

Can cards be destroyed (taken out of the game) as it is played ?

Are there rules about who should shuffle and when ?

Are there rules about who should deal and when ?

Can the rules change (evolve) at "run time" ?

Put it another way: you can't safely design an abstraction without knowing what
the abstraction is going to be used /for/. Which is in support of Stefan's
point:

> I do not like the idea of designing a card game /before/
> I know exactly /which/ card game it is at all.

even though I don't at all agree with his idea of starting in a procedureal
mode then switching to OO later (in fact I wouldn't be /able/ to do things his
way -- I find classic procedural code a lot harder to think about and/or create
than the OO kind).

-- chris

[Eric Sosman]

On 12/18/2012 12:10 AM, Gene Wirchenko wrote:
> On Mon, 17 Dec 2012 21:28:07 -0500, Arne Vajhøj <ar...@vajhoej.dk>
> wrote:
>
>> On 12/17/2012 9:18 PM, Gene Wirchenko wrote:
>>> On Mon, 17 Dec 2012 20:55:21 -0500, Arne Vajhøj <ar...@vajhoej.dk>
>>> 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.
>
> And how would you handle the aces?
>
> A-6-4-3-2 is ace high, but A-5-4-3-2 is actually 5-4-3-2-A (a
> five-high straight).

In some "high-low" games, A-5-4-3-2 can be both a
five-high straight *and* an Ace with four low cards,
possibly winning both the "high" and "low" shares of
the pot.

--
Eric Sosman
eso...@comcast-dot-net.invalid

[lipska the kat]

On 18/12/12 13:09, Chris Uppal wrote:

> lipska the kat wrote:
>
> Just want to point out that your OO "modelling" here is making quite a few
> asumptions about what kind of game we are going to want to play with the cards.
> I'm not saying that's a bad thing, but it could /get/ bad if you were doing it
> without being aware of it.

Not sure why you chose to put the word "modelling" in inverted commas,
let's just assume that you were highlighting the process. Anyway, it's
OK to make assumptions, that's how we progress.

Everything you mention below are rules, they do not impact in any way
whatsoever the abstractions of Card, Pack, Deck, Dealer shuffle, deal or
make the tea

> For instance:
>
> Can cards be marked as part of the game ? (Legaloloy, I mean -- for
> instance "cheating" might be allowed as part of the game)

This is a rule of the game, you are modelling the game, not the
abstractions you will use to play it, a markable card simply extends
Card and will be a new class, say, MarkableCard extends Card, you are
going through the "modelling" process in front of your very eyes.

>
> If we have> 1 pack, are the two 2 of Hearts considered /identical/, or are
> they distinguished in some way ? (Perhaps by the colours of the backs of the
> cards).

Again a rule of the game, nothing to do with the top level abstractions.
If during the modelling process you discover you need to invent a new
Class to deal with some situation that makes the original abstraction
unworkable then invent something, just make sure to keep the UML up to
date :-)

> Can new packs be added to the game as it is played ?

Rule, no impact on the top level abstractions

>
> Can cards be destroyed (taken out of the game) as it is played ?

ditto

>
> Are there rules about who should shuffle and when ?

A 'rule' you said it yourself

>
> Are there rules about who should deal and when ?

rule

>
> Can the rules change (evolve) at "run time" ?

A meta rule no less;

>
> Put it another way: you can't safely design an abstraction without knowing what
> the abstraction is going to be used /for/. Which is in support of Stefan's
> point:

But we do know what it/they is/are going to be used for, a game of
cards. A pack of cards is static. It's a well known and understood
concept that most humans can grasp. I don't care what game you are
playing a pack of card is a pack of cards. End of. Why cloud your
thinking. to use a favourite 'bulls**it' bingo phrase, Abstract the
[Cards] away from the problem space. Park them, assume you have them,
develop stubs, do whatever you have to do to remove the need to worry
about a Pack of Cards from your thinking ... Do the same for Deck and
Dealer, write an interface with method stubs, write code, reiterate,
challenge your assumptions.

When I start on a new problem I usually start writing code by the end of
the first day, even if it's just getting some package names down with a
bunch of empty classes that I think might help me to solve the problem.
Often (more often than you might think) the problem hasn't even been
fully defined when I start, in fact the definition changes as I go
along. As I model part of the system, questions arise. When I put those
questions to the stakeholders I often get 'oh I hadn't thought of that'
and a new facet of the problem becomes apparent. If I waited until I had
all the answers I'd be living in a cardboard box outside Liverpool
Street station

OO is hard. Getting those first few abstractions is often the hardest
part of all.

>
>> I do not like the idea of designing a card game /before/
>> I know exactly /which/ card game it is at all.
>
> even though I don't at all agree with his idea of starting in a procedureal
> mode then switching to OO later (in fact I wouldn't be /able/ to do things his
> way -- I find classic procedural code a lot harder to think about and/or create
> than the OO kind).

The bottom line is you need to tease out the rules or the 'how' from the
'what' or, in our case the classes that will be used to implement the
concept. It's quite straightforward once you get the hang of it. ;-)

[infin...@hotmail.com]

Wow! Lots of great discussion going on here.

This in no way, shape, or form negates or takes away anything from any of the wonderful comments already posted, but let me add some details to help clarify the original post;

As stated in the OP, I consider a deck to be 52 cards with 4 suits. Those suits are Hearts, Clubs, Diamonds, Spades. Aces could be valued as 1 or 11.

I'm not exactly sure what card game I will be programming at this time. I've never done a card game before, so I will start with something extremely minor, perhaps a Memory style game where you have 52 cards face down in 4 rows of 13. You turn them over two at a time and hope for a matching pair (by face/value, ie. 2 of Hearts and 2 of Spades). Maybe I'll start even smaller, with only 16 cards.

Eventually I would like to progress to something like Magic: The Gathering (or the Alchemy droid app) with several hundreds of cards, with various values and abilities.

Thank you all again for your comments. They are extremely helpful.

I3D

[lipska the kat]

On 18/12/12 14:32, infin...@hotmail.com wrote:

> I'm not exactly sure what card game I will be programming at this time.

Interesting, what do our procedural programmer(s) make of this then.
The OP isn't sure what game he will be programming ....

I suggest you start writing some code

Start with Card ... what form should Card take, from what you've said
I'll venture that Card might be abstract, all cards have a value
(assumption) so the value could be in Card or at least a placeholder to
be getting on with ... maybe Value is a Class or Interface the value of
a card could be '2' or 'gatekeeper' or 'Death' if you are playing Tarot.

DefaultCard could extend this, DefaultCard might have a 'Rank' so an
instance of DefaultCard might contain a 2 (from Card) and a 'Heart' from
DefaultCard .. the two of Hearts. TarotCard extends Card, some tarots
have values some don't, that's OK, it's still a Card.

More importantly your Deck will deal with Cards only
List<Card> deck doesn't say anything about Card other than it is a Card,
it can still be shuffled, dealt, cut etc etc, where do you think the
methods deal, shuffle and cut go ? Once this is out of the way you will
find yourself overwhelmed with ideas for card games, maybe you can even
invent your own, you've already got the base abstractions written and tested

Don't get too caught up in the detail to begin with, get the grunt work
out of the way first and MOST IMPORTANTLY don't be afraid to throw code
away, If you make a mistake you will have learned something, use that
knowledge to improve your design and move on.

Let us know how you get on.

Good luck and enjoy

[Eric Sosman]

On 12/18/2012 10:05 AM, lipska the kat wrote:
> On 18/12/12 14:32, infin...@hotmail.com wrote:
>
>> I'm not exactly sure what card game I will be programming at this time.
>
> Interesting, what do our procedural programmer(s) make of this then.
> The OP isn't sure what game he will be programming ....
>
> I suggest you start writing some code

He doesn't know what he wants to do, yet your advice is
"start writing some code?"

Ye flippin' gods.

--
Eric Sosman
eso...@comcast-dot-net.invalid

[lipska the kat]

Yes, start writing code
What do you suggest he does, Sit there twiddling his fingers.

I bet you have a pre-meeting meeting to discuss what to discuss in the
meeting don't you. Ye gods and little Indians, I've battled with the
likes of you all my professional life. I always deliver though because I
get code down and learn from it.

Write code, make mistakes, refactor, reiterate ... LEARN

Or sit on your hands lamenting your inability to get past the first obstacle

jeez

[Eric Sosman]

The nice part about working with no goal in mind
is that you can declare victory whenever it suits you.
Don't raise the bar: Hide it!

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Gene Wirchenko]

On Tue, 18 Dec 2012 08:53:58 -0500, Eric Sosman
<eso...@comcast-dot-net.invalid> wrote:

>On 12/18/2012 12:10 AM, Gene Wirchenko wrote:

[snip]

>> And how would you handle the aces?
>>
>> A-6-4-3-2 is ace high, but A-5-4-3-2 is actually 5-4-3-2-A (a
>> five-high straight).
>
> In some "high-low" games, A-5-4-3-2 can be both a
>five-high straight *and* an Ace with four low cards,
>possibly winning both the "high" and "low" shares of
>the pot.

Right. I have rarely ever played high-low and forgot about them.
Does anyone else have an exception to ambush us with? <g>

Sincerely,

Gene Wirchenko

[lipska the kat]

On 18/12/12 16:44, Eric Sosman wrote:
> On 12/18/2012 11:27 AM, lipska the kat wrote:

[snip]

>
> The nice part about working with no goal in mind
> is that you can declare victory whenever it suits you.
> Don't raise the bar: Hide it!

Yes of course, you are right. The secret to a long career in software
engineering is to hide the bar ... now I know where I've been going
wrong all these years.

[Gene Wirchenko]

On Tue, 18 Dec 2012 16:27:28 +0000, lipska the kat
<lipska...@yahoo.co.uk> wrote:

>On 18/12/12 16:07, Eric Sosman wrote:
>> On 12/18/2012 10:05 AM, lipska the kat wrote:
>>> On 18/12/12 14:32, infin...@hotmail.com wrote:
>>>
>>>> I'm not exactly sure what card game I will be programming at this time.
>>>
>>> Interesting, what do our procedural programmer(s) make of this then.
>>> The OP isn't sure what game he will be programming ....
>>>
>>> I suggest you start writing some code
>>
>> He doesn't know what he wants to do, yet your advice is
>> "start writing some code?"
>>
>> Ye flippin' gods.
>
>Yes, start writing code
>What do you suggest he does, Sit there twiddling his fingers.

I suggest that designing comes before writing code.

>I bet you have a pre-meeting meeting to discuss what to discuss in the
>meeting don't you. Ye gods and little Indians, I've battled with the

Straw man.

No, but I do work out what is needed in terms of features and
then work out the sorts of entities that I will need to implement
these.

>likes of you all my professional life. I always deliver though because I
>get code down and learn from it.

I write code, too, but the measure of a system is not just the
code. Its organisation counts for a lot.

>Write code, make mistakes, refactor, reiterate ... LEARN

Or one can design and make far fewer mistakes.

>Or sit on your hands lamenting your inability to get past the first obstacle

Another straw man.

>jeez

Sincerely,

Gene Wirchenko

[Patricia Shanahan]

I think that sort of issue could be handled by having game-dependent
Comparator<Card,Card> implementations, rather than making Card Comparable.

I would be more concerned about jokers, which do not follow the
(suit,value) pattern.

Patricia

[lipska the kat]

On 18/12/12 17:21, Gene Wirchenko wrote:
> On Tue, 18 Dec 2012 16:27:28 +0000, lipska the kat
> <lipska...@yahoo.co.uk> wrote:
>
>> On 18/12/12 16:07, Eric Sosman wrote:
>>> On 12/18/2012 10:05 AM, lipska the kat wrote:
>>>> On 18/12/12 14:32, infin...@hotmail.com wrote:

[snip]

>> Yes, start writing code
>> What do you suggest he does, Sit there twiddling his fingers.
>
> I suggest that designing comes before writing code.

I agree ... but if you are suggesting that you do all the designing
before you start to write a line of code then I humbly suggest that that
approach is fundamentally and profoundly flawed.

Just IME mind you, I'm sure you are not suggesting that.

Actually I suggest that they proceed in parallel.

>> I bet you have a pre-meeting meeting to discuss what to discuss in the
>> meeting don't you. Ye gods and little Indians, I've battled with the
>
> Straw man

Cheese sandwich

.
>
> No, but I do work out what is needed in terms of features and
> then work out the sorts of entities that I will need to implement
> these.

Entities, hmm, a word heavy with meaning to anyone who has ever written
EJBs. We deal in Classes, packages, components and Interfaces in Object
Oriented software engineering with Java, entities reflect persistence
schemata.

<Makes sweeping statement then withdraws to safe distance>

>> likes of you all my professional life. I always deliver though because I
>> get code down and learn from it.
>
> I write code, too, but the measure of a system is not just the
> code. Its organisation counts for a lot.

Concur

>
>> Write code, make mistakes, refactor, reiterate ... LEARN
>
> Or one can design and make far fewer mistakes.

Well this depends on your approach to design doesn't it (see above)

>> Or sit on your hands lamenting your inability to get past the first obstacle
>
> Another straw man.

Egg mayo on Rye, easy on the mayo

I forgotten how much fun the Usenet thing can be.

[Joshua Cranmer]

In the card game "capitalism," the highest card is a 2. ISTR a variant
where the highest card is a 3 as well....

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

[markspace]

On 12/18/2012 6:32 AM, infin...@hotmail.com wrote:

> Wow! Lots of great discussion going on here.

It's just the normal noises in here. We'll argue about anything really.

> time. I've never done a card game before, so I will start with
> something extremely minor, perhaps a Memory style game where you have

Don't forget that if you do make a standard deck, then nothing will
match. Unless you match on the values only, for example, and ignore suits.

[Gene Wirchenko]

On Tue, 18 Dec 2012 17:39:02 +0000, lipska the kat

<lipska...@yahoo.co.uk> wrote:

>On 18/12/12 17:21, Gene Wirchenko wrote:
>> On Tue, 18 Dec 2012 16:27:28 +0000, lipska the kat
>> <lipska...@yahoo.co.uk> wrote:
>>
>>> On 18/12/12 16:07, Eric Sosman wrote:
>>>> On 12/18/2012 10:05 AM, lipska the kat wrote:
>>>>> On 18/12/12 14:32, infin...@hotmail.com wrote:
>
>[snip]
>
>>> Yes, start writing code
>>> What do you suggest he does, Sit there twiddling his fingers.
>>
>> I suggest that designing comes before writing code.
>
>I agree ... but if you are suggesting that you do all the designing
>before you start to write a line of code then I humbly suggest that that
>approach is fundamentally and profoundly flawed.

No, but I do design code before I write it. The big design comes
first, then pieces of smaller design, then the code associated with
the smaller design. Repeat the last two steps as needed.

>Just IME mind you, I'm sure you are not suggesting that.
>
>Actually I suggest that they proceed in parallel.

For a given piece of code, design comes first.

>>> I bet you have a pre-meeting meeting to discuss what to discuss in the
>>> meeting don't you. Ye gods and little Indians, I've battled with the
>>
>> Straw man
>
>Cheese sandwich

>> No, but I do work out what is needed in terms of features and
>> then work out the sorts of entities that I will need to implement
>> these.
>
>Entities, hmm, a word heavy with meaning to anyone who has ever written
>EJBs. We deal in Classes, packages, components and Interfaces in Object
>Oriented software engineering with Java, entities reflect persistence
>schemata.
>
><Makes sweeping statement then withdraws to safe distance>

Or simply a word meaning something of interest. If code, it
might be a class or a procedure. It might also be who is using the
system, the hardware required, and so. It could also be things one
must consider such as privacy laws.

>>> likes of you all my professional life. I always deliver though because I
>>> get code down and learn from it.
>>
>> I write code, too, but the measure of a system is not just the
>> code. Its organisation counts for a lot.
>
>Concur
>
>>
>>> Write code, make mistakes, refactor, reiterate ... LEARN
>>
>> Or one can design and make far fewer mistakes.
>
>Well this depends on your approach to design doesn't it (see above)

Of course. How could it be otherwise?

>>> Or sit on your hands lamenting your inability to get past the first obstacle
>>
>> Another straw man.
>
>Egg mayo on Rye, easy on the mayo
>
>I forgotten how much fun the Usenet thing can be.

Maybe you should consider a conversation with colleagues a higher
priority than trolling.

Sincerely,

Gene Wirchenko

[Eric Sosman]

On 12/18/2012 12:23 PM, Patricia Shanahan wrote:
> On 12/18/2012 9:13 AM, Gene Wirchenko wrote:
>> On Tue, 18 Dec 2012 08:53:58 -0500, Eric Sosman
>> <eso...@comcast-dot-net.invalid> wrote:
>>
>>> On 12/18/2012 12:10 AM, Gene Wirchenko wrote:
>>
>> [snip]
>>
>>>> And how would you handle the aces?
>>>>
>>>> A-6-4-3-2 is ace high, but A-5-4-3-2 is actually 5-4-3-2-A (a
>>>> five-high straight).
>>>
>>> In some "high-low" games, A-5-4-3-2 can be both a
>>> five-high straight *and* an Ace with four low cards,
>>> possibly winning both the "high" and "low" shares of
>>> the pot.
>>
>> Right. I have rarely ever played high-low and forgot about them.
>> Does anyone else have an exception to ambush us with? <g>
>
> I think that sort of issue could be handled by having game-dependent
> Comparator<Card,Card> implementations, rather than making Card Comparable.

A comparator might have a hard time declaring "Ace is lower
than Deuce" and "Ace is higher than Deuce" simultaneously ...

And then, there are games where two identical ranks in the
same hand can have different values. With A-A-9, for example, a
Blackjack player would get the desired total of 21 by counting
one Ace as a 1 and the other as an 11. (This appears to be the
class of game the O.P. is interested in.)

> I would be more concerned about jokers, which do not follow the
> (suit,value) pattern.

Other pattern-busters might be the Jacks of Spades and Hearts.
When "one-eyed Jacks are wild," they can be of any rank or suit.
(I've read that the King of Diamonds is sometimes considered wild,
but have never actually encountered the practice.)

--
Eric Sosman
eso...@comcast-dot-net.invalid

[lipska the kat]

On 18/12/12 18:40, Gene Wirchenko wrote:
> On Tue, 18 Dec 2012 17:39:02 +0000, lipska the kat
> <lipska...@yahoo.co.uk> wrote:

[snip]

>
> No, but I do design code before I write it. The big design comes
> first, then pieces of smaller design, then the code associated with
> the smaller design. Repeat the last two steps as needed.
>
>> Just IME mind you, I'm sure you are not suggesting that.
>>
>> Actually I suggest that they proceed in parallel.
>
> For a given piece of code, design comes first.

Well if you call the mental process that we go through when we write a
piece of code 'design' then I agree but are you really saying that you
have never just written some code to test your thoughts BEFORE you
commit your thoughts to a formal model ... I find that hard to believe

[snip]

> Maybe you should consider a conversation with colleagues a higher
> priority than trolling.

Yes, this is an interesting point.
It's often appears to be the case that if someone doesn't agree with you
then they are trolling ... I often disagree with people but I don't call
them trolls.

Disappointing but sadly predictable.

[Eric Sosman]

On 12/18/2012 12:39 PM, lipska the kat wrote:
> On 18/12/12 17:21, Gene Wirchenko wrote:
>> On Tue, 18 Dec 2012 16:27:28 +0000, lipska the kat
>> <lipska...@yahoo.co.uk> wrote:
>>
>>> On 18/12/12 16:07, Eric Sosman wrote:
>>>> On 12/18/2012 10:05 AM, lipska the kat wrote:
>>>>> On 18/12/12 14:32, infin...@hotmail.com wrote:
>
> [snip]
>
>>> Yes, start writing code
>>> What do you suggest he does, Sit there twiddling his fingers.
>>
>> I suggest that designing comes before writing code.
>
> I agree ... but if you are suggesting that you do all the designing
> before you start to write a line of code then I humbly suggest that that
> approach is fundamentally and profoundly flawed.

Gene does not appear to take any such position, and I
most certainly do not. One need not (usually cannot) complete
all of the design ahead of time, because the implementation
process itself will produce surprises pleasant and unpleasant,
and these can be "learning opportunities." Knuth suggests the
learning can be so valuable that it can be a Good Thing to lose
all the code partway through development! (TAOCP section 1.4.1)

However, the fraction of design to be completed before
embarking on construction need not be an integer. When you
propose "all" as the only alternative to "none," you are being
silly. When you claim that people who disagree with you
subscribe to that false dichotomy, you are being an ass.

--
Eric Sosman
eso...@comcast-dot-net.invalid

[lipska the kat]

On 18/12/12 19:12, Eric Sosman wrote:
> On 12/18/2012 12:39 PM, lipska the kat wrote:
>> On 18/12/12 17:21, Gene Wirchenko wrote:
>>> On Tue, 18 Dec 2012 16:27:28 +0000, lipska the kat
>>> <lipska...@yahoo.co.uk> wrote:
>>>
>>>> On 18/12/12 16:07, Eric Sosman wrote:
>>>>> On 12/18/2012 10:05 AM, lipska the kat wrote:
>>>>>> On 18/12/12 14:32, infin...@hotmail.com wrote:
>>
>> [snip]
>>
>>>> Yes, start writing code
>>>> What do you suggest he does, Sit there twiddling his fingers.
>>>
>>> I suggest that designing comes before writing code.
>>
>> I agree ... but if you are suggesting that you do all the designing
>> before you start to write a line of code then I humbly suggest that that
>> approach is fundamentally and profoundly flawed.
>
> Gene does not appear to take any such position,

I'm sure 'Gene' can speak for himself.

>and I most certainly do not.

Glad to hear it

> One need not (usually cannot) complete
> all of the design ahead of time, because the implementation
> process itself will produce surprises pleasant and unpleasant,
> and these can be "learning opportunities." Knuth suggests the
> learning can be so valuable that it can be a Good Thing to lose
> all the code partway through development! (TAOCP section 1.4.1)

Yeees, and how many MD's, clients and other stake holders/bill payers
will fall for that one. You're not an academic by any chance are you. I
employed an academic once ... he lasted three days, couldn't even get
Eclipse to work. Or maybe I'm being an ass again.

> However, the fraction of design to be completed before
> embarking on construction need not be an integer.

You HAVE to be an academic, only an academic would come out with that one.

> When you
> propose "all" as the only alternative to "none," you are being
> silly.

I wasn't claiming any such thing, I was asking a question, or is THAT
also trolling now.

> When you claim that people who disagree with you
> subscribe to that false dichotomy, you are being an ass.

Ah, name calling, how quaint.

Really I expected better that this 'Gene' seems to be vaguely grounded
in reality but you are all negative so far.

Shame

[Gene Wirchenko]

On Tue, 18 Dec 2012 13:49:16 -0500, Eric Sosman
<eso...@comcast-dot-net.invalid> wrote:

[snip]

> Other pattern-busters might be the Jacks of Spades and Hearts.
>When "one-eyed Jacks are wild," they can be of any rank or suit.
>(I've read that the King of Diamonds is sometimes considered wild,
>but have never actually encountered the practice.)

I used to play "Hooks, Crooks, One-Eyed Jacks, and the Man with
the Axe". Hooks are 2's; crooks are 7's. The man with the axe is the
king of diamonds.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Tue, 18 Dec 2012 19:05:55 +0000, lipska the kat

<lipska...@yahoo.co.uk> wrote:

>On 18/12/12 18:40, Gene Wirchenko wrote:
>> On Tue, 18 Dec 2012 17:39:02 +0000, lipska the kat
>> <lipska...@yahoo.co.uk> wrote:
>
>[snip]
>
>>
>> No, but I do design code before I write it. The big design comes
>> first, then pieces of smaller design, then the code associated with
>> the smaller design. Repeat the last two steps as needed.
>>
>>> Just IME mind you, I'm sure you are not suggesting that.
>>>
>>> Actually I suggest that they proceed in parallel.
>>
>> For a given piece of code, design comes first.
>
>Well if you call the mental process that we go through when we write a
>piece of code 'design' then I agree but are you really saying that you
>have never just written some code to test your thoughts BEFORE you
>commit your thoughts to a formal model ... I find that hard to believe

Of course I have. My thoughts? They are the first part of the
design for that code.

>[snip]
>
>> Maybe you should consider a conversation with colleagues a higher
>> priority than trolling.
>
>Yes, this is an interesting point.
>It's often appears to be the case that if someone doesn't agree with you
>then they are trolling ... I often disagree with people but I don't call
>them trolls.

I did not call you a troll. To be precise, you are leaning that
way.

>Disappointing but sadly predictable.

And here I thought you were enjoying USENET. You did state "I
forgotten how much fun the Usenet thing can be." upthread.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Tue, 18 Dec 2012 19:39:58 +0000, lipska the kat

<lipska...@yahoo.co.uk> wrote:

>On 18/12/12 19:12, Eric Sosman wrote:
>> On 12/18/2012 12:39 PM, lipska the kat wrote:
>>> On 18/12/12 17:21, Gene Wirchenko wrote:
>>>> On Tue, 18 Dec 2012 16:27:28 +0000, lipska the kat
>>>> <lipska...@yahoo.co.uk> wrote:
>>>>
>>>>> On 18/12/12 16:07, Eric Sosman wrote:
>>>>>> On 12/18/2012 10:05 AM, lipska the kat wrote:
>>>>>>> On 18/12/12 14:32, infin...@hotmail.com wrote:
>>>
>>> [snip]
>>>
>>>>> Yes, start writing code
>>>>> What do you suggest he does, Sit there twiddling his fingers.
>>>>
>>>> I suggest that designing comes before writing code.
>>>
>>> I agree ... but if you are suggesting that you do all the designing
>>> before you start to write a line of code then I humbly suggest that that
>>> approach is fundamentally and profoundly flawed.
>>
>> Gene does not appear to take any such position,
>
>I'm sure 'Gene' can speak for himself.

I sure can, but what Eric wrote states my case wonderfully well.

[snip]

Sincerely,

Gene Wirchenko

[Wayne]

On 12/17/2012 9:37 PM, Arne Vajhøj wrote:
> 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
>
>

That's only for a bridge/poker deck. A pinochle deck consists of two copies
of each of the 9, 10, jack, queen, king, and ace cards of all four suits,
for 48 cards per deck. Aces are always considered high. Pinochle follows a
nonstandard card ordering. The complete ordering from highest to lowest
is A, 10, K, Q, J, 9. [quoted from Wikipedia]

Trying to generalize all card games with a single abstraction is probably a mistake.
If you limit the card games to those with hands that use a bridge/poker deck,
you probably want a unique ID for each card. Then the game class should implement
a handValue(Set<Card>) method, which may return a set of HandValues (rather
than a single value; it depends on the game I suppose). The
implementation can map Cards to value(s) in a given game context. The
error seems to be trying to put the valuation logic in the Card enum; the
values don't seem to be static enough to me.

--
Wayne

[Arne Vajhøj]

On 12/18/2012 4:34 AM, lipska the kat wrote:
> On 18/12/12 02:03, Arne Vajhøj wrote:
>> 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.
>
> Really, well thank you for pointing that out
>
> [snip]
>
>>> 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.
>
> Like I said, it was just an outline.
>
> In my house we play games that use a subset of a complete deck,
> sometimes we play a game that uses only the lower ranks of several packs
> of cards
>
> A Pack of cards contains 54 cards including two jokers.
> a Deck of cards contains the cards required to play a game, not the same
> thing at all ... hey look, we're already starting to come up with some
> new classes, cool huh.

That would not be the definitions I would use.

But you could certainly define them that way.

Arne

[Arne Vajhøj]

On 12/18/2012 4:34 AM, lipska the kat wrote:

> These type of questions/issues would come out in the wash. You need a
> place to start, often the final result looks nothing like the first
> iteration. Object Oriented software engineering is an iterative process.
> More that that it is a state of mind.

OO A/D/P should be independent of waterfall vs iterative.

Arne

[Arne Vajhøj]

On 12/18/2012 12:10 AM, Gene Wirchenko wrote:

> On Mon, 17 Dec 2012 21:28:07 -0500, Arne Vajhøj <ar...@vajhoej.dk>
> wrote:
>
>> On 12/17/2012 9:18 PM, Gene Wirchenko wrote:
>>> On Mon, 17 Dec 2012 20:55:21 -0500, Arne Vajhøj <ar...@vajhoej.dk>
>>> 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.

>
> And how would you handle the aces?
>
> A-6-4-3-2 is ace high, but A-5-4-3-2 is actually 5-4-3-2-A (a
> five-high straight).

That does not relate to whether Java enum has an order
or not.

But anyway - even with a natural order, then a game
specific ordering can be allowed.

Arne

[Arne Vajhøj]

On 12/18/2012 11:07 AM, Eric Sosman wrote:
> On 12/18/2012 10:05 AM, lipska the kat wrote:
>> On 18/12/12 14:32, infin...@hotmail.com wrote:
>>
>>> I'm not exactly sure what card game I will be programming at this time.
>>
>> Interesting, what do our procedural programmer(s) make of this then.
>> The OP isn't sure what game he will be programming ....
>>
>> I suggest you start writing some code
>
> He doesn't know what he wants to do, yet your advice is
> "start writing some code?"

If we are talking about a real project that is going to end up
with XXX KLOC, then start coding would be pointless.

But for a beginner wanting to learn programming and Java, then
start coding may actually be a fine advice.

Arne

[Arne Vajhøj]

On 12/18/2012 12:23 PM, Patricia Shanahan wrote:

An abstract Card class with two sub classes RegularCard and Joker??

Arne

[Arne Vajhøj]

If the logic can be described precisely, then it can be
implemented in code.

I somewhat suspect that stuff like this will not result
in pretty code.

Arne

[Arne Vajhøj]

On 12/18/2012 6:45 PM, Wayne wrote:
> On 12/17/2012 9:37 PM, Arne Vajhøj wrote:
>> 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.
>

> That's only for a bridge/poker deck. A pinochle deck consists of two copies
> of each of the 9, 10, jack, queen, king, and ace cards of all four suits,
> for 48 cards per deck. Aces are always considered high. Pinochle follows a
> nonstandard card ordering. The complete ordering from highest to lowest
> is A, 10, K, Q, J, 9. [quoted from Wikipedia]
>
> Trying to generalize all card games with a single abstraction is probably a mistake.

Sounds right.

> If you limit the card games to those with hands that use a bridge/poker deck,
> you probably want a unique ID for each card. Then the game class should implement
> a handValue(Set<Card>) method, which may return a set of HandValues (rather
> than a single value; it depends on the game I suppose). The
> implementation can map Cards to value(s) in a given game context. The
> error seems to be trying to put the valuation logic in the Card enum; the
> values don't seem to be static enough to me.

Having game specific values does not preclude having a
natural order.

Arne

[Eric Sosman]

Yes. But my principal point in all of this is that it cannot
always be implemented in *simple* code. Given the variety of card
games, it is folly to try to capture the notion of "card" in a
single, game-independent way. The same holds true for many other
problem domains as well: It is fruitless to model "a card" or
"a stock market" or "a person" in isolation from the model in
which the card/market/person will be represented.

The fundamental strength of O-O is that *sometimes* such
problem-oblivious models can be created, and *sometimes* the
next problem in line will be able to re-use the model. The
fundamental fallacy of O-O zealots is that such models are
independent of the problem; they nearly always aren't.

> I somewhat suspect that stuff like this will not result
> in pretty code.

(Shrug.) If you want to model something, you choose your
own level of fidelity. An old story tells of an engineer, a
physicist, and a mathematician tasked with finding the wind
resistance of a proposed design for a railway locomotive. The
engineer suggests building a full-scale wind tunnel, putting a
mock-up of the locomotive inside, and measuring the drag with a
simple spring scale.

"Wasteful!" cries the physicist. "The whole thing is fully
explained by the following enormous system of partial differential
equations, for which we can get numerical solutions with only six
and a half months' time on the world's largest supercomputer."

"Tut-tut," says the mathematician. "You empiricists are all
alike, rushing to measurements and approximations when a simple
grasp of theory would render everything clear to the suitably
rigorous mind. Now attend: Consider a spherical train ..."

(You think I'm kidding? There exist astrophysical models of
stellar structure in *one* dimension: radial distance from center.
So much for angular momentum and solar flares, eh?)

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Eric Sosman]

On 12/18/2012 8:07 PM, Arne Vajhøj wrote:
> On 12/18/2012 11:07 AM, Eric Sosman wrote:
>> On 12/18/2012 10:05 AM, lipska the kat wrote:
>>> On 18/12/12 14:32, infin...@hotmail.com wrote:
>>>
>>>> I'm not exactly sure what card game I will be programming at this time.
>>>

>>> I suggest you start writing some code
>>
>> He doesn't know what he wants to do, yet your advice is
>> "start writing some code?"
>
> If we are talking about a real project that is going to end up
> with XXX KLOC, then start coding would be pointless.

On the contrary: If your goal is to accumulate KLOC so you
can boast about them at your salary review, you should *never*
waste time in design!

> But for a beginner wanting to learn programming and Java, then
> start coding may actually be a fine advice.

He who is aimless can never miss.

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Arne Vajhøj]

On 12/18/2012 9:11 PM, Eric Sosman wrote:
> On 12/18/2012 8:07 PM, Arne Vajhøj wrote:
>> On 12/18/2012 11:07 AM, Eric Sosman wrote:
>>> On 12/18/2012 10:05 AM, lipska the kat wrote:
>>>> On 18/12/12 14:32, infin...@hotmail.com wrote:
>>>>
>>>>> I'm not exactly sure what card game I will be programming at this
>>>>> time.
>>>>
>>>> I suggest you start writing some code
>>>
>>> He doesn't know what he wants to do, yet your advice is
>>> "start writing some code?"
>>
>> If we are talking about a real project that is going to end up
>> with XXX KLOC, then start coding would be pointless.
>
> On the contrary: If your goal is to accumulate KLOC so you
> can boast about them at your salary review, you should *never*
> waste time in design!

Funny.

>> But for a beginner wanting to learn programming and Java, then
>> start coding may actually be a fine advice.
>
> He who is aimless can never miss.

If he learns to code Java, then it does not matter
much if the resulting code changes along the way.

If he starts at the top with let us say ZF, then I can
almost guarantee that he will neither learn Java nor
get any working code out of it.

Arne

[lipska the kat]

On 19/12/12 02:07, Eric Sosman wrote:
> On 12/18/2012 8:11 PM, Arne Vajh�j wrote:

[snip]

>> If the logic can be described precisely, then it can be
>> implemented in code.
>
> Yes. But my principal point in all of this is that it cannot
> always be implemented in *simple* code. Given the variety of card
> games, it is folly to try to capture the notion of "card" in a
> single, game-independent way.

OK, I guess we got off on the wrong foot so I'll try again.
I'm not trying to be condescending. I'm genuinely interested in your
response.

Can we agree that the names we give things help our understanding of
what those things are supposed to represent ?

In our world, it almost always the case that, sooner or later, someone
who was not present during the design phase of our system will need to
understand it in order to maintain it. Good names for system concepts help.

If we think of a Card in the 'games played with cards' universe then,
unless I've missed something a card is a small piece of cloth or
cardboard that has some numbers, pictures or symbols on one or both
sides. Maybe a better name would be PlayingCard

The concept of a PlayingCard is fixed in our collective memory by virtue
of the experiences we have of PlayingCards in our lives.
Of course different cultures use cards in different ways to play
different games but the point is, if you ask anyone on the planet what a
PlayingCard is them I suggest that the basic concept will always be there.

Can we also agree that any system needs a starting point and a good
starting point might be a name that seems to capture at least part of
what our system is supposed to do.

If we agree on these few simple principles then I'd be interested to
know what name you might use for your starting point if not PlayingCard
(or Card).

I can't think of a card game that does not use PlayingCards of one sort
or another. One might argue that Tarot is not a game yet uses Cards.
This might mean that PlayingCard is unsuitable, so we fall back to Card
with PlayingCard a possible later specialization.

If the base abstraction is not Card then what else might describe what a
Card is better than 'Card'

[Patricia Shanahan]

On 12/18/2012 6:07 PM, Eric Sosman wrote:
...

> Yes. But my principal point in all of this is that it cannot
> always be implemented in *simple* code. Given the variety of card
> games, it is folly to try to capture the notion of "card" in a
> single, game-independent way. The same holds true for many other
> problem domains as well: It is fruitless to model "a card" or
> "a stock market" or "a person" in isolation from the model in
> which the card/market/person will be represented.

I think there are a lot of games based on mass produced packs of playing
cards. That gives a solid basis for a class Card. It should not be
Comparable because there is no common ordering.

Each game would need its own Comparator<Card>, assuming cards can be
compared in the game. It would also need its own value of Deck, a
collection of cards that is used in that game.

Patricia

[lipska the kat]

To progress the design a little I'd suggest that maybe, Card is an
abstract class that exposes (at least) two methods, show() and hide();
The default implementations do nothing.

I can't think of a card game that doesn't do at least one of these.

I can also see Pack which contains n Card[s] depending on type (54 hcds
cards is one pack I can think of)

and also Deck which contains a number of Cards required to play the
game, at this point the 'rules' are irrelevant.

The contents of Pack and Deck may be the same for some games, in this
case Deck has a constructor that takes a Pack, semantically however they
are different.

[Gene Wirchenko]

On Wed, 19 Dec 2012 09:33:59 +0000, lipska the kat
<lipska...@yahoo.co.uk> wrote:

>On 19/12/12 02:07, Eric Sosman wrote:

>> On 12/18/2012 8:11 PM, Arne Vajhøj wrote:
>
>[snip]
>
>>> If the logic can be described precisely, then it can be
>>> implemented in code.
>>
>> Yes. But my principal point in all of this is that it cannot
>> always be implemented in *simple* code. Given the variety of card
>> games, it is folly to try to capture the notion of "card" in a
>> single, game-independent way.
>
>OK, I guess we got off on the wrong foot so I'll try again.
>I'm not trying to be condescending. I'm genuinely interested in your
>response.
>
>Can we agree that the names we give things help our understanding of
>what those things are supposed to represent ?

Sure. Remember, though, that the name is not the thing.

>In our world, it almost always the case that, sooner or later, someone
>who was not present during the design phase of our system will need to
>understand it in order to maintain it. Good names for system concepts help.

Sure. I go to the trouble of documenting them in a client
billing system that I maintain. I am likely the only one to look at
that part of the code, but I do it anyway because solid definitions
are important.

>If we think of a Card in the 'games played with cards' universe then,
>unless I've missed something a card is a small piece of cloth or
>cardboard that has some numbers, pictures or symbols on one or both
>sides. Maybe a better name would be PlayingCard
>
>The concept of a PlayingCard is fixed in our collective memory by virtue
>of the experiences we have of PlayingCards in our lives.
>Of course different cultures use cards in different ways to play
>different games but the point is, if you ask anyone on the planet what a
>PlayingCard is them I suggest that the basic concept will always be there.

But there are so many examples of definitions. I prefer to
solidify the definition that I need before coding. My program may be
a one-off so my card definition is never used elsewhere. If I suspect
that it reasonably might be reused, then I will look more generally
for that definition. At some point though, it is better to decide on
something and run with it.

>Can we also agree that any system needs a starting point and a good
>starting point might be a name that seems to capture at least part of
>what our system is supposed to do.
>
>If we agree on these few simple principles then I'd be interested to
>know what name you might use for your starting point if not PlayingCard
>(or Card).

I would not bother. Determining the name comes as part of the
design. I might even have more than one name because I might have to
handle special cases.

>I can't think of a card game that does not use PlayingCards of one sort
>or another. One might argue that Tarot is not a game yet uses Cards.
>This might mean that PlayingCard is unsuitable, so we fall back to Card
>with PlayingCard a possible later specialization.

That depends on your definition of the term. If you mean the
run-of-the-garden 52-54 or so card deck, I can think of some easily.
Gang of Four is one example.

>If the base abstraction is not Card then what else might describe what a
>Card is better than 'Card'

Who knows yet? That is what the analysis and design are for.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Tue, 18 Dec 2012 20:04:31 -0500, Arne Vajhøj <ar...@vajhoej.dk>
wrote:

>On 12/18/2012 12:10 AM, Gene Wirchenko wrote:

[snip]

>> A-6-4-3-2 is ace high, but A-5-4-3-2 is actually 5-4-3-2-A (a
>> five-high straight).
>
>That does not relate to whether Java enum has an order
>or not.
>
>But anyway - even with a natural order, then a game
>specific ordering can be allowed.

My point is that, in this case, there would be more than one
order.

Sincerely,

Gene Wirchenko

[Lew]

lipska the kat wrote:
> I can't think of a card game that does not use PlayingCards of one sort

By definition. Hardly a ground-shaking point.

> or another. One might argue that Tarot is not a game yet uses Cards.

Tarot is not a game because it's the name of the deck.

There are games that use Tarot cards, and many decks that are based more directly
on Tarot than the French deck that seems to be your imprinted standard.

> This might mean that PlayingCard is unsuitable, so we fall back to Card

Whatever. What do you do with Tarot cards that is not a game, hm?

> with PlayingCard a possible later specialization.

> If the base abstraction is not Card then what else might describe what a
> Card is better than 'Card'

Do you have a point here?

Why do you refer to "the" base abstraction? The "base abstraction" of what?
There are several such in a card-game simulation.

The "base abstraction" of a playing card is the abstract notion of a playing card,
as you say. So?

Once you break out of tautologies you can find the entrance to design.

The key in O-O is not finding one "base abstraction" (BTW, what exactly do you mean
by that phrase?) but a cooperating set of them, and identifying the interactions.

So to model a card game, you need several types in the model. One approach will
comprise 'PlayingCard', 'Rule', 'CardGame', 'Deck', 'Shoe' and other semantic features.

It is the interaction of these that makes up a model.

--
Lew

[Lew]

On Wednesday, December 19, 2012 4:06:14 AM UTC-8, Patricia Shanahan wrote:
> Each game would need its own Comparator<Card>, assuming cards can be
> compared in the game. It would also need its own value of Deck, a
> collection of cards that is used in that game.

Except, as pointed out upthread, the semantics of 'Comparator' are not a good match
for many card games such as Blackjack or ones that use wild cards.

--
Lew

[Leif Roar Moldskred]

lipska the kat <lipska...@yahoo.co.uk> wrote:

> I can't think of a card game that does not use PlayingCards of one sort
> or another.

Uno and Memory are the classic ones that spring to mind. There's also
all the collectible card games, with Magic the Gathering and Pokemon
as the two best known ones, and there's a fashion to make "board-less"
boardgames consisting only of various cards (Dominion by Donald
X. Vaccarino is a really good such game.)

(This is just meant as trivia, not a contribution to the technical
discussion. It doesn't make sense to try and design a domain model
that encompasses both classic playing cards and Magic the Gathering --
the domains are only superficially similar.)

--
Leif Roar Moldskred

[Lew]

Leif Roar Moldskred wrote:

> lipska the kat wrote:
>> I can't think of a card game that does not use PlayingCards of one sort
>> or another.
>
>
>
> Uno and Memory are the classic ones that spring to mind. There's also

I'm not familiar with Memory, but Uno most certainly does use playing cards.

> all the collectible card games, with Magic the Gathering and Pokemon
> as the two best known ones, and there's a fashion to make "board-less"
> boardgames consisting only of various cards (Dominion by Donald
> X. Vaccarino is a really good such game.)

All those are games that use playing cards.

> (This is just meant as trivia, not a contribution to the technical
> discussion. It doesn't make sense to try and design a domain model
> that encompasses both classic playing cards and Magic the Gathering --
> the domains are only superficially similar.)

But both do involve playing cards.

Just different kinds.

--
Lew

[Leif Roar Moldskred]

Lew <lewb...@gmail.com> wrote:
>
> I'm not familiar with Memory, but Uno most certainly does use playing cards.

Ah, my bad. I see I misread the post I was replying too.

--
Leif Roar Moldskred

[Arne Vajhøj]

Yes, but game specific order will be provided by game while
natural order is provided by card.

Arne

[lipska the kat]

I've been reading this thread from day 1 and I have to say the fug is
beginning to clear. It appears that what you are proposing is a
'bottom-up' design process. I guess you expect and hope that 'Objects'
will automagically appear when the time is right.

The original post is dated 16th Dec 2012 it is now the 20th and how much
progress has been made.

I think the main problem is that that there is no clear statement of
requirements.

I'll try to interpret the OPs slightly vague requirements to get
something concrete down, this is obviously a first pass and will need
work so comments welcome.

A system is required that will allow one or more players to play a game
of cards. A game of cards consists of one or more packs of cards or a
subset of one or more packs of cards (hereafter referred to as a deck) a
set of rules, and one or more players. Users of the system will be able
to choose from a selection of games and the system should be able to
support new games as required.

I'll make a first pass top down analysis and suggest that Game, Card,
Player, Pack, Rule and Deck might be useful abstractions.

[Gene Wirchenko]

On Wed, 19 Dec 2012 19:18:16 -0500, Arne Vajhøj <ar...@vajhoej.dk>
wrote:

[snip]

>> My point is that, in this case, there would be more than one
>> order.
>
>Yes, but game specific order will be provided by game while
>natural order is provided by card.

Try game-specific order*S*.

What natural order? And how do you just the use of the word
"natural"? "preferred" might be a better choice of words.

And why would a card provide an order anyway? Order is a
property of a deck, not a card.

Sincerely,

Gene Wirchenko

[Patricia Shanahan]

Outside a specific game, what is the proper default for ace-high vs.
ace-low, and where do you put the jokers, the NaNs of playing cards?

Perhaps more importantly, why do we need an order?

Patricia

[Gene Wirchenko]

On Thu, 20 Dec 2012 09:30:09 -0800, Patricia Shanahan <pa...@acm.org>
wrote:

[snip]

>Outside a specific game, what is the proper default for ace-high vs.
>ace-low, and where do you put the jokers, the NaNs of playing cards?

"the NaNs of playing cards": a nice turn of phrase, madam!

That is even better than Gang of Four's rules which have that the
green phoenix is not a green card, the yellow phoenix is not a yellow
card, and the red dragon is not a red card. OTOH, the multi-coloured
one can be stated to be any of the colours for the purpose of flushes
and straight flushes.

>Perhaps more importantly, why do we need an order?

Many card games require order to rank hands or determine which
card beats which.

I want to see a game where the ranking is circular. There would
be no ties on two different-value cards if the number of values in the
circle is odd.

Implement with computing the normal difference in values. If
this number is six or less, the nominally higher card would be ranked
higher; otherwise, the nominally lower card would be ranked higher.
Example: An ace would beat a king, queen, jack, ten, nine, or eight
and lose to a two, three, four, five, six, or seven.

Sincerely,

Gene Wirchenko

[Patricia Shanahan]

On 12/20/2012 1:35 PM, Gene Wirchenko wrote:
> On Thu, 20 Dec 2012 09:30:09 -0800, Patricia Shanahan <pa...@acm.org>

...

>> Perhaps more importantly, why do we need an order?
>
> Many card games require order to rank hands or determine which
> card beats which.

I agree that a game may require and impose an order, but each game's
order is different. Indeed, the order can even change during a game. For
example, the ranking for winning trick in a bridge game depends on the
contract and the suit of the trick's lead card.

I expect many games to declare and use a Comparator<Card>. I'm
suggesting that Card should not itself be Comparable.

Patricia

[lipska the kat]

A Comparator is an abstraction of what we as human beings do when we
compare values. You can have a Comparator that compares in any way you want.

A Comparator would effectively implement a sub set of the rules of the
game. Seems a perfectly logical suggestion to me

Once again if not a Comparator then what. It's all vary well playing
devils advocate but sooner or later something actually needs to be
written down. Asking 'why do we need an order' exposes either a
surprisingly poor insight into a very common phenomena (the Playing
Card/Card Game) or a pathalogical reluctance to commit oneself to a
potential solution for fear of it being 'wrong' somewhere down the line.

Object Oriented software engineering provides many mechanisms to deal
with changing requirements, altered and enhanced insights and good old
fashioned 'mistakes' Of course first you need to have the idea.

[Daniel Pitts]

On 12/21/12 12:58 AM, lipska the kat wrote:
> On 20/12/12 22:00, Patricia Shanahan wrote:
>> On 12/20/2012 1:35 PM, Gene Wirchenko wrote:
>>> On Thu, 20 Dec 2012 09:30:09 -0800, Patricia Shanahan <pa...@acm.org>
>> ...
>>>> Perhaps more importantly, why do we need an order?
>>>
>>> Many card games require order to rank hands or determine which
>>> card beats which.
>>
>> I agree that a game may require and impose an order, but each game's
>> order is different. Indeed, the order can even change during a game. For
>> example, the ranking for winning trick in a bridge game depends on the
>> contract and the suit of the trick's lead card.
>>
>> I expect many games to declare and use a Comparator<Card>. I'm
>> suggesting that Card should not itself be Comparable.
>>
>
> A Comparator is an abstraction of what we as human beings do when we
> compare values. You can have a Comparator that compares in any way you
> want.
>
> A Comparator would effectively implement a sub set of the rules of the
> game. Seems a perfectly logical suggestion to me
>
> Once again if not a Comparator then what.

Patricia is agreeing with the use of Comparator, and against the use of
Comparable, two very different interfaces.

[lipska the kat]

Read the entire post before commenting. I agree with Patricia

[Gene Wirchenko]

On 25 Dec 2012 21:32:37 GMT, r...@zedat.fu-berlin.de (Stefan Ram)
wrote:

[snip]

> So, here's how to do it:
>
> If you already did similar projects like this before or have
> obtained a good education about projects like this, then
> design first and implement later.
>
> But if you never did similar projects before, then either
> let someone else do the design (who DID similar projects
> before) or start to try to code and experience (more in a
> bottom-up manner and with enough time for many refactorings
> or rewrites) or start to read some books about the desing of

Yes. When I have played with languages, I often take the example
of a times table. I first implement it minimally. Then, I get into
formatting, allowing ranges to be selected, allowing input of ranges,
having different operations, and so on.

> such projects (also do the exercises from the books).

Be sure to modify the exercises from the books, too. You can
think of a slightly different thing that you would like to try, can't
you?

Some books have sample programs and if you do not try modifying
them to your own ends, you can think you know something when you don't
really. Non-trivial modifying requires digging in and helps you
learn.

Sincerely,

Gene Wirchenko

[Patricia Shanahan]

On 12/25/2012 1:32 PM, Stefan Ram wrote:
...

> But if you never did similar projects before, then either
> let someone else do the design (who DID similar projects
> before) or start to try to code and experience (more in a
> bottom-up manner and with enough time for many refactorings
> or rewrites) or start to read some books about the desing of

> such projects (also do the exercises from the books).
>

I have a variant on this. I often don't actually write the code, but I
spend a lot of time imagining the outlines of the code. Especially if
I'm working in a language I know well, I can often think up mid-level
structures that I know I could program, if they turned out to be useful.
I then think of the high level design in terms of those mid-level
structures.

Patricia

[Lew]

To describe the elephant from yet another projection, I use a combination
of intuitive and cognitive models derived from the linguistic space of the
application domain.

The intuitive portion matches domain-specific language ("TPS Report") with
a ready-to-hand skill set of noun-verb object metamodels.

"Hmm, a report /has-a/ {title, ...}, /is-a/ {Retrievable, Readable, ...}."

The metamodel is the idea of "/has-a/" and "/is-a/", the notion of objects
having types, attributes, and behaviors, and the toolbox containing
polymorphism, assertions and all the panoply of design and programming skills.

Mixing in or out aspects such as functional programming is rather a mind
twist, but really an extension of the metamodel. I use different programming
languages, so I will slot in architecturally parallel constructs such as
first-class functions vs. SAM interfaces to the same spot in the mental
model.

I've got in trouble with certain managers for using skeleton Java interfaces
to generate UML diagrams, because "it isn't time to code yet; we're doing
diagrams". I defended my approach as being at the same level of architectural
design as diagramming, and consonant with how a programmer thinks. They let it
go.

Begrudgingly.

But it was exactly what Patricia describes. If you think structurally, it might
look like code - but hey, structure's structure however you describe it.

You sketch what you can see, try it as quickly as you can get a prototype up
(hours, not days), and proceed in however fashion you proceed to fill in the
details.

As a fillip, I correlate Java elements to UML differently from (and therefore
superior to, by my definition :-') some. Java idiomatically, and
controversially, exposes all attributes as accessor and mutator (getter and
setter) methods. Some diagram 'getX()' and 'setX()' methods as methods under
UML. Tsk. They're still attributes - 'get' and 'set' are just conventions
for expressing their public face. Architecturally, at the level where UML
can hope to do any good, I diagram them as attributes.

I'm not religious about it. If a paycheck is at stake I'll diagram them
as blueberries if you like.

--
Lew

[Arne Vajhøj]

On 12/26/2012 4:21 PM, Lew wrote:
> As a fillip, I correlate Java elements to UML differently from (and therefore
> superior to, by my definition :-') some. Java idiomatically, and
> controversially, exposes all attributes as accessor and mutator (getter and
> setter) methods. Some diagram 'getX()' and 'setX()' methods as methods under
> UML. Tsk. They're still attributes - 'get' and 'set' are just conventions
> for expressing their public face. Architecturally, at the level where UML
> can hope to do any good, I diagram them as attributes.

I completely agree.

UML diagrams are to provide overview not duplicate all the details
in the code.

Attributes are important for the overview.

Getters, setters, toString etc. are not important for the overview.

Arne

[lipska the kat]

On 26/12/12 21:21, Lew wrote:
> Patricia Shanahan wrote:
>> Stefan Ram wrote:

[snip]

> You sketch what you can see, try it as quickly as you can get a prototype up
> (hours, not days), and proceed in however fashion you proceed to fill in the
> details.

I think I already said this didn't I ?
Ah well, we got there in the end.

[Robert Klemme]

On 26.12.2012 22:21, Lew wrote:

> To describe the elephant from yet another projection, I use a combination
> of intuitive and cognitive models derived from the linguistic space of the
> application domain.
>
> The intuitive portion matches domain-specific language ("TPS Report") with
> a ready-to-hand skill set of noun-verb object metamodels.
>
> "Hmm, a report /has-a/ {title, ...}, /is-a/ {Retrievable, Readable, ...}."
>
> The metamodel is the idea of "/has-a/" and "/is-a/", the notion of objects
> having types, attributes, and behaviors, and the toolbox containing
> polymorphism, assertions and all the panoply of design and programming skills.

I find the CRC card approach quite nice here: those cards also capture
major aspects without going in too much detail. I rarely use them
physically but I use the concept to remind myself of R and C.

> But it was exactly what Patricia describes. If you think structurally, it might
> look like code - but hey, structure's structure however you describe it.

Right. That's also the reason why I prefer Visio with the free set of
stencils for UML modeling over any other UML tool (especially those with
a proper UML model in the background or even roundtrip engineering)
because I can add visual elements not part of UML standard to help
getting ideas across.

> As a fillip, I correlate Java elements to UML differently from (and therefore
> superior to, by my definition :-') some. Java idiomatically, and
> controversially, exposes all attributes as accessor and mutator (getter and
> setter) methods. Some diagram 'getX()' and 'setX()' methods as methods under
> UML. Tsk. They're still attributes - 'get' and 'set' are just conventions
> for expressing their public face. Architecturally, at the level where UML
> can hope to do any good, I diagram them as attributes.

Same here.

> I'm not religious about it. If a paycheck is at stake I'll diagram them
> as blueberries if you like.

I'd prefer strawberries - more space to write something. ;-)

Cheers

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[Patricia Shanahan]

On 12/27/2012 2:51 AM, Robert Klemme wrote:
...

> Right. That's also the reason why I prefer Visio with the free set of
> stencils for UML modeling over any other UML tool (especially those with
> a proper UML model in the background or even roundtrip engineering)
> because I can add visual elements not part of UML standard to help
> getting ideas across.

...

Round trip UML reminds me of a situation I encountered in the early
1970's. We had a manager who insisted that there had to be an up-to-date
flow chart covering the entire code in each application. The
applications were written in NEAT/3 Level 2, an assembly language. There
was a flow chart standard that required a very rigid format, close to
single column.

We did really use flow charts in some situations, but not for whole
applications, and in much more flexible layouts. The whole program
design documents tended to be text describing the data structures,
functions, and main algorithms in a program.

Fortunately, someone had written an application that read the source for
a program, and generated an ASCII flow chart from it. We ran it, bound
the line printer paper in big binders, showed them to the manager, and
stowed them away.

The flow charts were longer than the assembly language code, no more
readable, and contained a proper subset of the information in the code,
including its comments, so they were really useless. They gave no
architectural or design insight. They existed only in order to be able
to say we had a flow chart.

Round trip UML smells of that situation.

Patricia

[Robert Klemme]

On 27.12.2012 17:46, Patricia Shanahan wrote:

> The flow charts were longer than the assembly language code, no more
> readable, and contained a proper subset of the information in the code,
> including its comments, so they were really useless. They gave no
> architectural or design insight. They existed only in order to be able
> to say we had a flow chart.

Neat! ;-)

> Round trip UML smells of that situation.

Yes. I believe the reason for that is that diagram != diagram: a
diagram generated from some input can only apply standard layout rules.
But a diagram created by a human will have deliberate layout and a
human will also likely refrain from putting all classes of a single
package (or even a complete source tree) in a single diagram.

And in order to update a diagram from source code you always need
additional data - either the old diagram or some form of meta data which
describes placement. For things created in code you would still get
default placement and a human would have to edit the diagram anyway.

And if the roundtrip tool would also to need to handle renaming of
entities like classes and interfaces (a common operation during
refactoring) there would also need to be support from the IDE to record
these types of changes and update diagrams properly.

Then we still haven't covered how a project with a few thousand classes
is handled efficiently (not in terms of CPU cycles but in terms of
diagrams which provide benefit to the reader).

Plenty of years ago I got to evaluate the first version of a roundtrip
UML tool which supported sequence diagrams (as representations of
methods). I create a sequence diagram with two method invocations both
of which returned String. The code didn't compile. It turned out that
both variables had the same name. I couldn't believe they did not think
of that situation when I stumbled across this after five minutes. Well,
my company didn't by the tool then. :-)

Kind regards

[Arne Vajhøj]

On 12/27/2012 5:51 AM, Robert Klemme wrote:
> Right. That's also the reason why I prefer Visio with the free set of
> stencils for UML modeling over any other UML tool (especially those with
> a proper UML model in the background or even roundtrip engineering)
> because I can add visual elements not part of UML standard to help
> getting ideas across.

UML is actually rather flexible.

It defines stereotypes and do allow for special graphical
representations of those.

And it also allows comments with a given graphical
representation to be used.

Arne

[Arne Vajhøj]

On 12/20/2012 6:05 AM, lipska the kat wrote:
> On 20/12/12 00:18, Arne Vajhøj wrote:
>> On 12/19/2012 1:14 PM, Gene Wirchenko wrote:
>>> On Tue, 18 Dec 2012 20:04:31 -0500, Arne Vajhøj <ar...@vajhoej.dk>
>>> wrote:
>>>
>>>> On 12/18/2012 12:10 AM, Gene Wirchenko wrote:
>>>
>>> [snip]
>>>
>>>>> A-6-4-3-2 is ace high, but A-5-4-3-2 is actually 5-4-3-2-A (a
>>>>> five-high straight).
>>>>
>>>> That does not relate to whether Java enum has an order
>>>> or not.
>>>>
>>>> But anyway - even with a natural order, then a game
>>>> specific ordering can be allowed.
>>>
>>> My point is that, in this case, there would be more than one
>>> order.
>>
>> Yes, but game specific order will be provided by game while
>> natural order is provided by card.
>
> I've been reading this thread from day 1 and I have to say the fug is
> beginning to clear. It appears that what you are proposing is a
> 'bottom-up' design process. I guess you expect and hope that 'Objects'
> will automagically appear when the time is right.

????

I don't think the fog is clearing.

I am mostly for top-down design not bottom-up design.

That a game specific comparator belongs in the game and
not the card class has nothing to do with top-down
versus bottom-up.

Arne

[Arne Vajhøj]

On 12/20/2012 12:01 PM, Gene Wirchenko wrote:
> On Wed, 19 Dec 2012 19:18:16 -0500, Arne Vajhøj <ar...@vajhoej.dk>
> wrote:
>
> [snip]
>
>>> My point is that, in this case, there would be more than one
>>> order.
>>
>> Yes, but game specific order will be provided by game while
>> natural order is provided by card.
>
> Try game-specific order*S*.

OK.

> What natural order?

If 100 people are given 3 cards with 7, 8 and 9 and asked to
put the cards in order do you think all combinations will show
up evenly distributed or that the order 7 8 9 will show up 100
times?

> And how do you just the use of the word
> "natural"? "preferred" might be a better choice of words.

No.

The traditional term used in IT is "natural order".

> And why would a card provide an order anyway? Order is a
> property of a deck, not a card.

????

The natural order is defined by the items not the container.

The natural order of int is defined for int not for int[]
or List<Integer>.

Arne

[Lew]

Arne Vajhøj wrote:
> lipska the kat wrote:

>> I've been reading this thread from day 1 and I have to say the fug is
>> beginning to clear. It appears that what you are proposing is a
>> 'bottom-up' design process. I guess you expect and hope that 'Objects'
>> will automagically appear when the time is right.
>
> ????
>
> I don't think the fog is clearing.
>
> I am mostly for top-down design not bottom-up design.
>
> That a game specific comparator belongs in the game and
> not the card class has nothing to do with top-down
> versus bottom-up.

The inclusion of quotes around the terms "bottom-up" and "Objects" by the OP
raises suspicions that there is some alternative use of the terms in play here.

--
Lew

[Arne Vajhøj]

Aces and jokers are not as natural sorted as the rest.

> Perhaps more importantly, why do we need an order?

I can think of a few reasons:
* it reflects how people view cards
* it is practical to be able to enumerate over all values
(and that implies an order)

Arne

[Arne Vajhøj]

But also note that the discussion actually started with
something that both has an order and allows arithmetic (int)
versus something that only has an order (enum).

Arne

[Arne Vajhøj]

On 12/20/2012 5:00 PM, Patricia Shanahan wrote:
> On 12/20/2012 1:35 PM, Gene Wirchenko wrote:
>> On Thu, 20 Dec 2012 09:30:09 -0800, Patricia Shanahan <pa...@acm.org>
> ...
>>> Perhaps more importantly, why do we need an order?
>>
>> Many card games require order to rank hands or determine which
>> card beats which.
>
> I agree that a game may require and impose an order, but each game's
> order is different. Indeed, the order can even change during a game. For
> example, the ranking for winning trick in a bridge game depends on the
> contract and the suit of the trick's lead card.
>
> I expect many games to declare and use a Comparator<Card>.

I think that everybody is agreeing about that.

> I'm
> suggesting that Card should not itself be Comparable.

That is the discussion. As explained in another post, then
I believe it makes sense.

Also note that at least the original claim just was that
card value had an ordering. A card ordering implies a card
value ordering (and a suit ordering), but a card value order
does not imply a card ordering.

Arne

[Arne Vajhøj]

On 12/21/2012 3:58 AM, lipska the kat wrote:
> On 20/12/12 22:00, Patricia Shanahan wrote:
>> On 12/20/2012 1:35 PM, Gene Wirchenko wrote:
>>> On Thu, 20 Dec 2012 09:30:09 -0800, Patricia Shanahan <pa...@acm.org>
>> ...
>>>> Perhaps more importantly, why do we need an order?
>>>
>>> Many card games require order to rank hands or determine which
>>> card beats which.
>>
>> I agree that a game may require and impose an order, but each game's
>> order is different. Indeed, the order can even change during a game. For
>> example, the ranking for winning trick in a bridge game depends on the
>> contract and the suit of the trick's lead card.
>>
>> I expect many games to declare and use a Comparator<Card>. I'm
>> suggesting that Card should not itself be Comparable.
>>
>
> A Comparator is an abstraction of what we as human beings do when we
> compare values. You can have a Comparator that compares in any way you
> want.
>
> A Comparator would effectively implement a sub set of the rules of the
> game. Seems a perfectly logical suggestion to me

A suggestion that Patricia actually made.

> Once again if not a Comparator then what. It's all vary well playing
> devils advocate but sooner or later something actually needs to be
> written down. Asking 'why do we need an order' exposes either a
> surprisingly poor insight into a very common phenomena (the Playing
> Card/Card Game) or a pathalogical reluctance to commit oneself to a
> potential solution for fear of it being 'wrong' somewhere down the line.

????

The topic of discussion is natural order of cards or card values out of
context of a specific game.

Asking if we need such an order is a very valid question.

I will argue that the answer is yes.

But asking the question neither expose poor insight or
anything pathological.

And using those terms about asking a valid design question
reveals that you are completely unsuited to work with other
people.

Arne

[Arne Vajhøj]

I must admit that I did not understand the "and hope that 'Objects'
will automagically appear when the time is right" part at all.

Neither "eventually some code will be done so objects can be
instantiated" nor "start with specialized classes and find
super classes until Object is reached" seems to relate
to the rest.

Arne

[Gene Wirchenko]

On Thu, 27 Dec 2012 21:48:58 -0500, Arne Vajhøj <ar...@vajhoej.dk>
wrote:

>On 12/20/2012 12:01 PM, Gene Wirchenko wrote:

[snip]

>> What natural order?
>
>If 100 people are given 3 cards with 7, 8 and 9 and asked to
>put the cards in order do you think all combinations will show
>up evenly distributed or that the order 7 8 9 will show up 100
>times?

Ah, a loaded question. Here is one of my own:

We make those 100 people work even more. We give them three
cards with A, K, Q and ask them to put the cards in order. I expect
that they will be ranked highest to lowest as [A, K, Q]. We then give
them three cards with 3, 2, A and ask them to put the cards in order.
This one is stickier. I expect that we will see the orders [3, 2, A]
and [A, 3, 2]. For those who pick the former, this implies [3, 2, A,
K, Q]. Oops!

>> And how do you just the use of the word
>> "natural"? "preferred" might be a better choice of words.
>
>No.
>
>The traditional term used in IT is "natural order".

I have never heard it. Live and learn.

>> And why would a card provide an order anyway? Order is a
>> property of a deck, not a card.
>
>????
>
>The natural order is defined by the items not the container.

Order is meaningless without having the concept of more than one
of an item.

Order is not defined by items. How does the integer 5 define
order for integers? The data type, not its values, defines the order.

>The natural order of int is defined for int not for int[]
>or List<Integer>.

Might you want to sort items by the order? What is the likely
signature of the sort procedure for, say int values?
void Sort(int);
or
void Sort(int []);
I suggest that the former does not make sense, but that the latter
does. It makes sense to sort an array, but sorting a single value
does not make much sense.

Sincerely,

Gene Wirchenko

[lipska the kat]

On 28/12/12 03:05, Arne Vajhøj wrote:
> On 12/21/2012 3:58 AM, lipska the kat wrote:
>> On 20/12/12 22:00, Patricia Shanahan wrote:
>>> On 12/20/2012 1:35 PM, Gene Wirchenko wrote:
>>>> On Thu, 20 Dec 2012 09:30:09 -0800, Patricia Shanahan <pa...@acm.org>
>>> ...

[snip]

>> A Comparator would effectively implement a sub set of the rules of the
>> game. Seems a perfectly logical suggestion to me
>
> A suggestion that Patricia actually made.

And I was agreeing with

>> Once again if not a Comparator then what. It's all vary well playing
>> devils advocate but sooner or later something actually needs to be
>> written down. Asking 'why do we need an order' exposes either a
>> surprisingly poor insight into a very common phenomena (the Playing
>> Card/Card Game) or a pathalogical reluctance to commit oneself to a
>> potential solution for fear of it being 'wrong' somewhere down the line.
>
> ????
>
> The topic of discussion is natural order of cards or card values out of
> context of a specific game.

> Asking if we need such an order is a very valid question.

We seem to be getting confused here.
There are two questions

1. 'Why do we need an order'

and

2. 'Is there such a thing as a 'natural order' [of a pack/deck] of cards'

These are two quite different questions.

I'll take the first one first

Asking 'why do we need an order' implies that the person asking the
question has never played a game of cards. I don't know how else to
interpret that question.

Now the second one

The Swiss have a game where Jack is high.
In our house we have a game where Ace can be high or low.
As for cribbage ...

These orderings are game specific, in fact they are part of the rules of
the game. So for any given game there may be a 'natural order' for a
hand and (possibly) another order for the result of playing that hand
against other hands. But is there an overall 'natural order' for all
decks/hands I'd say no given the ambiguity of the positional status of
Aces and jokers at the very least.

> I will argue that the answer is yes.

And I say no, bu it's just my POV

> But asking the question neither expose poor insight or
> anything pathological.
>
> And using those terms about asking a valid design question
> reveals that you are completely unsuited to work with other
> people.

Fascinating, really, the things you learn on Usenet.

Thank you, I'll inform my team of your analysis.