Prev: Question about ident service
Next: To what extent can Java be written in Cheese?
From: Rhino on 24 May 2010 00:52
Arne Vajh�j <arne(a)vajhoej.dk> wrote in
news:4bf9d898$0$272$14726298(a)news.sunsite.dk:

> 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: news(a)netfront.net ---
From: Rhino on 24 May 2010 01:07
Lew <noone(a)lewscanon.com> wrote in news:htclj0$7p5$1(a)news.albasani.net:

> 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: news(a)netfront.net ---
From: Lew on 24 May 2010 07:10
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
From: Arne Vajhøj on 24 May 2010 18:16
On 24-05-2010 01:07, Rhino wrote:
> Lew<noone(a)lewscanon.com> wrote in news:htclj0$7p5$1(a)news.albasani.net:
>> 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
From: Arne Vajhøj on 24 May 2010 18:21
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




First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Question about ident service
Next: To what extent can Java be written in Cheese?