Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

proper use of .java files (layout)

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-27-2012
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


 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      12-27-2012
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/
 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      12-27-2012
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

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-28-2012
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


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-28-2012
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 <(E-Mail Removed)>
>>> 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

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-28-2012
On 12/20/2012 12:01 PM, Gene Wirchenko wrote:
> On Wed, 19 Dec 2012 19:18:16 -0500, Arne Vajh°j <(E-Mail Removed)>
> 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


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-28-2012
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-28-2012
On 12/20/2012 12:30 PM, Patricia Shanahan wrote:
> On 12/20/2012 9:01 AM, Gene Wirchenko wrote:
>> On Wed, 19 Dec 2012 19:18:16 -0500, Arne Vajh°j <(E-Mail Removed)>
>> 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.

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


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-28-2012
On 12/27/2012 9:53 PM, Arne Vajh°j wrote:
> On 12/20/2012 12:30 PM, Patricia Shanahan wrote:
>> On 12/20/2012 9:01 AM, Gene Wirchenko wrote:
>>> On Wed, 19 Dec 2012 19:18:16 -0500, Arne Vajh°j <(E-Mail Removed)>
>>> 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.

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

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-28-2012
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 <(E-Mail Removed)>

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

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

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


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



Advertisments