From: Joshua Cranmer on
On 05/24/2010 01:07 AM, Rhino wrote:
> I always wondered why that exception was supposed to be useful....

Well, since you yourself seemed surprised at the utility, you should
probably have inquired as to why this should be done. A good tip for the
future. At worst, you learn something; at best, you avoid bad advice.

> Originally, I seem to recall putting constants in interfaces, then being
> told it was bad - I forget why - and that a standalone class for
> constants alone (the ones that public static final and where you write
> the names in caps with underscores for separators) was the way to go (as
> well as the private constructor).

Putting constants in standalone classes is right for some cases.
Nowadays, I believe most of those cases have been subsumed by the
introduction of enums.

> Darn, I was hoping that at least one thing in Java would be a simple
> obvious thing that I wouldn't have to think about for a long time.

All rules have exceptions. A key part of design, in my opinion, is being
able to coherently explain why the particular design and implementation
was chosen. Design is a necessarily thought-intensive process, so don't
worry about having to think about it. I can show you many train wrecks
I've written that have come about by insufficient design (granted, a
project due in a week that I'll likely never refer to again isn't
something I'm too worried about turning into a train wreck).

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
From: Arved Sandstrom on
Rhino wrote:
[ SNIP ]

> The reason this question is coming up is probably that I slavishly
> followed advice I was given at some point in the past and never really
> understood all the reasons for that advice - or why it might not be the
> right advice.
>
> Originally, I seem to recall putting constants in interfaces, then being
> told it was bad - I forget why - and that a standalone class for
> constants alone (the ones that public static final and where you write
> the names in caps with underscores for separators) was the way to go (as
> well as the private constructor).
>
> Obviously, I have to rethink this now too.
>
> Man, it seems like I'm having to rethink just about everything I've
> written. Working alone without a live mentor or regular walkthroughs with
> people who know more than you can definitely put you into a bad place....
>
> Maybe I need a different job strategy: instead of trying to convince
> employers/clients that I know what I'm doing, appeal to them for a job on
> the grounds that I want to learn how to do things RIGHT, instead of
> floundering like this.....
>
[ SNIP ]

> Darn, I was hoping that at least one thing in Java would be a simple
> obvious thing that I wouldn't have to think about for a long time.
>
> I LOVE what this language can do but it's discouraging to find that every
> tiny thing needs to be thought of very carefully to keep from doing
> something that will have bad consequences. COBOL, REXX and CSP were
> definitely easier in that regard ;-) But so much more limited too!
[ SNIP ]

Download the source for some tight, top-notch open-source projects.
*That* is your mentor. Mentors, really, because even with just a few
decent-sized OSS projects to review you'll be exposed to the work of
dozens of programmers. You can ask for recommendations here - my first
one would be JSF 2 from https://javaserverfaces.dev.java.net/.

At this stage of the game lots of rethinking isn't a bad thing. But pick
your battles - implementation of constants isn't exactly critical. You
could in fact go with a standalone constants class, each constant being
a public static final, named the way you describe, and it's not going to
be a serious problem. It's not optimal for the reasons that others have
suggested, but quite frankly it's not a big deal.

My recommendation is, back off a bit right now from trying to write a
perfect application. Look at others' high-quality source, and learn from
it. Start reading some good articles on OOP design - you need to know OO
basics before you can have a hope of writing decent OO code.

And food for thought: you mention "bad consequences". Well, can you list
what bad consequences might be? That can be an illuminating starting
point for figuring out how you would prevent those from occurring.
Unless you know what it is that you're trying _not_ to do then you're
adrift. For example, this kind of thinking along with some readings in
OPP design would have let you figure out the answers that you've been
given in this thread, which is a lot better than being spoonfed. :-)

AHS
From: Roedy Green on
On Mon, 24 May 2010 01:15:58 +0000 (UTC), Rhino
<no.offline.contact.please(a)example.com> wrote, quoted or indirectly
quoted someone who said :

>Is there any reason NOT to put _all_ of the constants used throughout the
>project in FooConstants? Or is it wiser to only move something to a
>XXXConstants class if it is used in more than one class?

I have a class called Config for all the constants you might
reasonably want to tweak when porting the code to a slightly different
project. For things like Regex expressions, which can be thought of
as part of the code, I find it better to put them in the sole class
where they are used.

As a general rule, make things private used in but a single class.
Make things default used in but a single project.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Beauty is our business.
~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)

Referring to computer science.
From: Arne Vajhøj on
On 25-05-2010 07:15, Roedy Green wrote:
> On Mon, 24 May 2010 01:15:58 +0000 (UTC), Rhino
> <no.offline.contact.please(a)example.com> wrote, quoted or indirectly
> quoted someone who said :
>> Is there any reason NOT to put _all_ of the constants used throughout the
>> project in FooConstants? Or is it wiser to only move something to a
>> XXXConstants class if it is used in more than one class?
>
> I have a class called Config for all the constants you might
> reasonably want to tweak when porting the code to a slightly different
> project. For things like Regex expressions, which can be thought of
> as part of the code, I find it better to put them in the sole class
> where they are used.

Maybe you should read the thread.

Arne

From: Rhino on
Lew <noone(a)lewscanon.com> wrote in news:htdmqn$koi$1(a)news.albasani.net:

> Rhino wrote:
>>> Darn, I was hoping that at least one thing in Java would be a simple
>> obvious thing that I wouldn't have to think about for a long time.
>>
>> I LOVE what this language can do but it's discouraging to find that
>> every tiny thing needs to be thought of very carefully to keep from
>> doing something that will have bad consequences. COBOL, REXX and CSP
>> were definitely easier in that regard ;-) But so much more limited
>> too!
>
> Java is no different from other languages in this regard. The kind of
> "think[ing] about for a long time" to which you refer is universal to
> programming, not specific to Java.
>
> Lew wrote:
>>> I usually put static finals generally, and constants particularly,
>>> as private in the class where they're needed, and give them wider
>>> access only when needed as needed. YAGNI.
>
> Rhino wrote:
>> That's the second time I've seen YAGNI in the last few days but I
>> still don't know what it means. I'm guessing it's something like
>> YMMV, Your Mileage May Vary?
>
> The acronym was explained to you when you asked before. By more than
> one. Why did you ignore the answers?
>
> I only used the acronym because I "knew" you knew what it meant by
> now.
>
> There's really no point in answering questions for someone who ignores
> the answers.
>
> Now go google it, for Chrissake!
>
> Sheesh.
>

Hey, we've got a LOT of threads going here and most of them have umpteen
subthreads and side discussions so it's a serious challenge keeping up
with it all. I'm already spending most of each day trying to monitor the
replies so that we finally get to something like a resolution. Forgive me
for missing some things....


--
Rhino