proper use of .java files (layout)

[Arne Vajhøj]

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

 

[Robert Klemme]

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

 

[Robert Klemme]

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

robert

 

[Arne Vajhøj]

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/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]

[snip]

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]

????

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.

 

[Arne Vajhøj]

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

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?

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]

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

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?

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)

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]

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]

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]

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.

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

No.

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

I have never heard it. Live and learn.

????

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

 

[John B. Matthews]

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.

In Java, each wrapper class of a primitive type implements the
Comparable interface, which "imposes a total ordering" that "is
referred to as the class's natural ordering." The
implementation gives each instance a way to compare itself to
another. The natural order can be used as a foundation for
domain order, sometimes expressed using a Comparator:

<http://www.codinghorror.com/blog/2007/12/sorting-for-humans-natural-sort-order.html>

 

[Gene Wirchenko]

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

[snip]

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?

Give 100 people the 7 of Hearts, 7 of Clubs, 7 of Spades and 7 of
Diamonds and ask them to put them in order ...

BWAHAHA! Good one!

Or is that hearts, spades, diamonds, clubs? <G> (That is the
order of trump suits in each hand of whist. The fifth hand has no
trump. Then, the cycle repeats.)

I personally use the order diamonds, hearts, spades, and clubs
for collecting suits when playing solitaire games.

[snip]

Sincerely,

Gene Wirchenko