proper use of .java files (layout)

A

Arne Vajhøj

[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
 
A

Arne Vajhøj

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
 
A

Arne Vajhøj

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.

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

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

Arne
 
A

Arne Vajhøj

On Tue, 18 Dec 2012 08:53:58 -0500, Eric Sosman

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

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
 
A

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.

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
 
E

Eric Sosman

On 12/18/2012 9:13 AM, Gene Wirchenko wrote:
On Tue, 18 Dec 2012 08:53:58 -0500, Eric Sosman

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

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

Eric Sosman

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

Arne Vajhøj

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.


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
 
G

Gene Wirchenko

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
 
G

Gene Wirchenko

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
 
L

Lew

lipska said:
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.
 
L

Lew

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

Lew

Leif said:
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.
 
A

Arne Vajhøj

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.

Arne
 
G

Gene Wirchenko

[snip]
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
 
G

Gene Wirchenko

[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
 
D

Daniel Pitts

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

Stefan Ram

But this is also a question of experience: If I would
already have written similar games, I might be able to
OOD a larger part of the program up-front.

I would like to generalized this idea:

Design is a fruit of experience. That's why usually
experienced programmers become software architects and not
the other way round. You can design if you did this before
and therefore know how it goes. The design results from the
application of experience to a new project.

But this is still domain specific: A software architect
from the 60s with experience in console applications
cannot immediatly design GUI software without further
preparation. An expert game programmer cannot suddenly
design database applications for business users.

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
such projects (also do the exercises from the books).
 
G

Gene Wirchenko

On 25 Dec 2012 21:32:37 GMT, (e-mail address removed)-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
 
L

Lew

Patricia said:
Stefan Ram wrote:
...

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.

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top