Prev: Question about ident service
Next: To what extent can Java be written in Cheese?
From: Rhino on 23 May 2010 21:15
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: news(a)netfront.net ---
From: markspace on 23 May 2010 21:32
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.
From: Arne Vajhøj on 23 May 2010 21:38
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

From: Lew on 23 May 2010 21:43
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
From: Rhino on 24 May 2010 00:50
markspace <nospam(a)nowhere.com> wrote in
news:htckvq$k5g$1(a)news.eternal-september.org:

> 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: news(a)netfront.net ---
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Question about ident service
Next: To what extent can Java be written in Cheese?