«

I'm really hoping this will be a straightforward non-controversial question
(for a change) on my part

I am doing a code review on some code that I want to put in a "code
portfolio" so I'm trying to figure out the best ways to do various things.

Specifically, I have about 20 classes right now in the main part of the
project that I'll be putting in the portfolio. There are a substantial
number of constants used in one place or another. I have _most_ of them in
a single class that is called FooConstants (where "Foo" is replaced by the
name of my project.) FooConstants has a private constructor that throws
UnsupportedOperationException (as suggested previously in this group) and
everything else in it is a static final, i.e. a constant.

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?

For instance, if I have a constant named FOO_FILE_NAME and it is used only
in class FooBlahBlah, is it better to leave the constant in FooBlahBlah
rather than forcing developers to have to go to another class to determine
(or change) its value? Or is it better to have all constants, wherever
used, all together in FooConstants?

Am I safe in assuming that if a Constant is used in more than one class and
it is supposed to have the same value in each case, that I definitely want
those constants centralized in my FooConstants class? Otherwise, if I put a
unique occurrence of each multiply-occuring constant, like FOO_LOG_PATH, in
each class where it occurs, it seems to be almost inevitable that
FOO_LOG_PATH will eventually have different values in each of the classes
where it is used.

--
Rhino

--- news://freenews.netfront.net/ - complaints: ---

Rhino wrote:

> 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 would do the opposite: move constants out of FooConstants and into
classes that are closer to where they belong conceptually or are consumed.

For example, JFrame.EXIT_ON_CLOSE (from memory, didn't compile check
that) gets used a lot in many of my applications, and indeed all over
the place in Swing applications in general. Does Sun put EXIT_ON_CLOSE
in a separate SunConstants class? Nope, the keep EXIT_ON_CLOSE close to
where it belongs and where it is used (consumed).

This makes more sense as applications grow larger. Can you imagine what
the size of SunConstants would be if Sun actually put every constant in
their API in that class? Yuck. It would be a nightmare to document or
read. So it's probably better that the constants relating to the JFrame
API are in the JFrame class, where you'd expect to find them, and expect
to see them documented.

Just my 2 cents here.

On 23-05-2010 21:15, Rhino wrote:
> I'm really hoping this will be a straightforward non-controversial question
> (for a change) on my part
>
> I am doing a code review on some code that I want to put in a "code
> portfolio" so I'm trying to figure out the best ways to do various things.
>
> Specifically, I have about 20 classes right now in the main part of the
> project that I'll be putting in the portfolio. There are a substantial
> number of constants used in one place or another. I have _most_ of them in
> a single class that is called FooConstants (where "Foo" is replaced by the
> name of my project.) FooConstants has a private constructor that throws
> UnsupportedOperationException (as suggested previously in this group) and
> everything else in it is a static final, i.e. a constant.
>
> 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?
>
> For instance, if I have a constant named FOO_FILE_NAME and it is used only
> in class FooBlahBlah, is it better to leave the constant in FooBlahBlah
> rather than forcing developers to have to go to another class to determine
> (or change) its value? Or is it better to have all constants, wherever
> used, all together in FooConstants?
>
> Am I safe in assuming that if a Constant is used in more than one class and
> it is supposed to have the same value in each case, that I definitely want
> those constants centralized in my FooConstants class? Otherwise, if I put a
> unique occurrence of each multiply-occuring constant, like FOO_LOG_PATH, in
> each class where it occurs, it seems to be almost inevitable that
> FOO_LOG_PATH will eventually have different values in each of the classes
> where it is used.

XxxxConstants with constants is not a very good pattern.

I would definitely move the constants to the classes where they
logical belong.

Typical the class that has methods that expects those
constants as input.

Also use enum instead of int constants for additional
type safety when possible.

For configuration stuff then use a configuration file
for flexibility. If it is a simple case then good old
Properties class should be sufficient.

Filenames and directories belong to the last category.

Arne

Rhino wrote:
> Specifically, I have about 20 classes right now in the main part of the
> project that I'll be putting in the portfolio. There are a substantial
> number of constants used in one place or another. I have _most_ of them in
> a single class that is called FooConstants (where "Foo" is replaced by the
> name of my project.) FooConstants has a private constructor that throws
> UnsupportedOperationException (as suggested previously in this group) and
> everything else in it is a static final, i.e. a constant.

It's silly to throw that exception in the private constructor. Only the class
itself can invoke the constructor. I prefer a private constructor with an
empty body.

"static final" is not the same as a "constant variable" in Java. A constant
can be non-static, and a final can be non-constant.

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

Depends. Probably not wise to put them all in one place - some constants (or
static finals) should be private, not public, ergo kept in the class where
they're used. Tightly coupling classes together is a bad idea often.

Like everything else, you have to do what makes sense. Some constants should
be in a project-wide class, sure. Others in a functional unit, for example,
data-access constants in a data-access utility class. Others should be
package-private. Some should be protected or private, for use only in an
inheritance hierarchy or the class itself, respectively.

You have to think each choice through. Access should be as wide as needed but
not wider, and as narrow as possible but not narrower.

> For instance, if I have a constant named FOO_FILE_NAME and it is used only
> in class FooBlahBlah, is it better to leave the constant in FooBlahBlah
> rather than forcing developers to have to go to another class to determine
> (or change) its value? Or is it better to have all constants, wherever
> used, all together in FooConstants?

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.

> Otherwise, if I put a
> unique occurrence of each multiply-occuring constant, like FOO_LOG_PATH, in
> each class where it occurs, it seems to be almost inevitable that
> FOO_LOG_PATH will eventually have different values in each of the classes
> where it is used.

Logging is usually configured in an external resource, like the
log4j.properties file for the log4j framework.

--
Lew

markspace <> wrote in
news:htckvq$k5g$:

> Rhino wrote:
>
>> 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 would do the opposite: move constants out of FooConstants and into
> classes that are closer to where they belong conceptually or are
> consumed.
>
> For example, JFrame.EXIT_ON_CLOSE (from memory, didn't compile check
> that) gets used a lot in many of my applications, and indeed all over
> the place in Swing applications in general. Does Sun put
> EXIT_ON_CLOSE in a separate SunConstants class? Nope, the keep
> EXIT_ON_CLOSE close to where it belongs and where it is used
> (consumed).
>
> This makes more sense as applications grow larger. Can you imagine
> what the size of SunConstants would be if Sun actually put every
> constant in their API in that class? Yuck. It would be a nightmare
> to document or read. So it's probably better that the constants
> relating to the JFrame API are in the JFrame class, where you'd expect
> to find them, and expect to see them documented.
>
> Just my 2 cents here.

I hadn't thought of the issue the way you present it. You make a lot of
good points. Thanks Markspace!

--
Rhino

--- news://freenews.netfront.net/ - complaints: ---

Arne Vajhøj <> wrote in
news:4bf9d898$0$272$:

> On 23-05-2010 21:15, Rhino wrote:
>> I'm really hoping this will be a straightforward non-controversial
>> question (for a change) on my part
>>
>> I am doing a code review on some code that I want to put in a "code
>> portfolio" so I'm trying to figure out the best ways to do various
>> things.
>>
>> Specifically, I have about 20 classes right now in the main part of
>> the project that I'll be putting in the portfolio. There are a
>> substantial number of constants used in one place or another. I have
>> _most_ of them in a single class that is called FooConstants (where
>> "Foo" is replaced by the name of my project.) FooConstants has a
>> private constructor that throws UnsupportedOperationException (as
>> suggested previously in this group) and everything else in it is a
>> static final, i.e. a constant.
>>
>> 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?
>>
>> For instance, if I have a constant named FOO_FILE_NAME and it is used
>> only in class FooBlahBlah, is it better to leave the constant in
>> FooBlahBlah rather than forcing developers to have to go to another
>> class to determine (or change) its value? Or is it better to have all
>> constants, wherever used, all together in FooConstants?
>>
>> Am I safe in assuming that if a Constant is used in more than one
>> class and it is supposed to have the same value in each case, that I
>> definitely want those constants centralized in my FooConstants class?
>> Otherwise, if I put a unique occurrence of each multiply-occuring
>> constant, like FOO_LOG_PATH, in each class where it occurs, it seems
>> to be almost inevitable that FOO_LOG_PATH will eventually have
>> different values in each of the classes where it is used.
>
> XxxxConstants with constants is not a very good pattern.
>
> I would definitely move the constants to the classes where they
> logical belong.
>
> Typical the class that has methods that expects those
> constants as input.
>
> Also use enum instead of int constants for additional
> type safety when possible.
>
Yes, I do that when practical.

> For configuration stuff then use a configuration file
> for flexibility. If it is a simple case then good old
> Properties class should be sufficient.
>
> Filenames and directories belong to the last category.
>
And there is the answer to my big concern: constants that are used in
several places. I expect that as I analyze them, a lot will turn out to
be filenames and directories. or configuration information which would be
better placed in properties files....

Thanks Arne!

--
Rhino

--- news://freenews.netfront.net/ - complaints: ---

Lew <> wrote in news:htclj0$7p5$:

> Rhino wrote:
>> Specifically, I have about 20 classes right now in the main part of
>> the project that I'll be putting in the portfolio. There are a
>> substantial number of constants used in one place or another. I have
>> _most_ of them in a single class that is called FooConstants (where
>> "Foo" is replaced by the name of my project.) FooConstants has a
>> private constructor that throws UnsupportedOperationException (as
>> suggested previously in this group) and everything else in it is a
>> static final, i.e. a constant.
>
> It's silly to throw that exception in the private constructor. Only
> the class itself can invoke the constructor. I prefer a private
> constructor with an empty body.
>
Someone on this group recommended that approach to me a few years back. I
don't remember who and I probably wouldn't say if I did; everyone's
entitled to be wrong once in a while

I always wondered why that exception was supposed to be useful....

> "static final" is not the same as a "constant variable" in Java. A
> constant can be non-static, and a final can be non-constant.
>
Sorry, once again I'm being imprecise. Blame it on the fact that my
knowledge of the terminology is less than complete....

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

>> 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?
>
> Depends. Probably not wise to put them all in one place - some
> constants (or static finals) should be private, not public, ergo kept
> in the class where they're used. Tightly coupling classes together is
> a bad idea often.
>
Okay....

> Like everything else, you have to do what makes sense. Some constants
> should be in a project-wide class, sure. Others in a functional unit,
> for example, data-access constants in a data-access utility class.
> Others should be package-private. Some should be protected or
> private, for use only in an inheritance hierarchy or the class itself,
> respectively.
>
> You have to think each choice through. Access should be as wide as
> needed but not wider, and as narrow as possible but not narrower.
>
Okay....

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!

>> For instance, if I have a constant named FOO_FILE_NAME and it is used
>> only in class FooBlahBlah, is it better to leave the constant in
>> FooBlahBlah rather than forcing developers to have to go to another
>> class to determine (or change) its value? Or is it better to have all
>> constants, wherever used, all together in FooConstants?
>
> 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.
>
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?

>> Otherwise, if I put a
>> unique occurrence of each multiply-occuring constant, like
>> FOO_LOG_PATH, in each class where it occurs, it seems to be almost
>> inevitable that FOO_LOG_PATH will eventually have different values in
>> each of the classes where it is used.
>
> Logging is usually configured in an external resource, like the
> log4j.properties file for the log4j framework.
>
Right. Like Arne said, things like that should be in a properties file,
coded as constants. Now I just have to get clearer on what should and
shouldn't be put in properties files. I may not have a lot of constants
in a centralized class by the time I'm done this exercise

Thanks for your guidance, Lew!

--
Rhino

--- news://freenews.netfront.net/ - complaints: ---

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.

--
Lew

On 24-05-2010 01:07, Rhino wrote:
> Lew<> wrote in news:htclj0$7p5$:
>> Rhino wrote:
>>> For instance, if I have a constant named FOO_FILE_NAME and it is used
>>> only in class FooBlahBlah, is it better to leave the constant in
>>> FooBlahBlah rather than forcing developers to have to go to another
>>> class to determine (or change) its value? Or is it better to have all
>>> constants, wherever used, all together in FooConstants?
>>
>> 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.
>>
> 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?

http://en.wikipedia.org/wiki/YAGNI

Arne

On 24-05-2010 01:07, Rhino wrote:
> 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.....

Or just conclude that something is good enough.

If your ambition is to write 10000 lines of perfect code, then
you will not be done until year 2050 (or maybe 2150).

There is always something that can be improved.

In 2 years you will write much better code than what you do now. But
in 4 years you will write much better code than what you will in 2
years. And so on.

Arne