public static final const primitives?

[kk_oop]

Any opinions about having an interface whose sole reason for existence
is to house some public static final const primitive values to be used
by other classes?

A couple points to consider (though feel free to comment beyond these):

Any thoughts on using an interface in this way vs. a class?

Any thoughts on making such constant primitives available through
public getters instead of through public attributes?

Thanks for any input!

Ken

 

[Wibble]

Be careful about assembling constants in a single interface
which server multiple roles. One of my least favorite antipatterns
is to fill an interface with public constants used by many
consumers.

It becomes hard to remove unused constants when they are no longer
referenced, without searching you're entire codebase. These tend
to become big incomprehensible bags of useless crap, obscuring the
roles of constants that are legitimately and valuably exposed.

I like to keep constants close to the 'owner' of that information so
that they are factored together.

Use setters/getters if it makes sense or you just like them. Write
unit tests for them if you choose to use them. Most people on this
group love them. I'm ambivalent.

 

[Wibble]

I also like:

x=Const.VALUE;

better than:

class A extends Const {
x = VALUE;
}

since you can tell where VALUE comes from.

 

[Lucy]

Be careful about assembling constants in a single interface
which server multiple roles. One of my least favorite antipatterns
is to fill an interface with public constants used by many
consumers.

It becomes hard to remove unused constants when they are no longer
referenced, without searching you're entire codebase. These tend
to become big incomprehensible bags of useless crap, obscuring the
roles of constants that are legitimately and valuably exposed.

I like to keep constants close to the 'owner' of that information so
that they are factored together.

Use setters/getters if it makes sense or you just like them. Write
unit tests for them if you choose to use them.

you mean something like

if(MYCONST != 5) System.out.println("MYCONST != 5");


Most people on this

 

[Patricia Shanahan]

Wibble wrote:
....

Use setters/getters if it makes sense or you just like
them. Write unit tests for them if you choose to use
them.

....

Why the emphasis on unit tests for getters and setters?

I try to allocate my testing effort according to the
probability of tests finding a bug. It's been a long time
since I've found a bug in a simple getter or setter - at
least as long as the time since I last hand wrote one. I
would rather add more tests of something likely to contain bugs.

Of course, more complicated getters and setters that contain
hand written code should have tests.

Patricia

 

[Chris Uppal]

Any thoughts on making such constant primitives available through
public getters instead of through public attributes?

One reason why you /might/ want to do that is that it would prevent the
compiler hard-wiring the values of those constants in the generated bytecode of
any method that referred to them. That has the small advantage that you can
change the values without breaking existing code, and the rather larger
advantage that automated tools can track the dependency between the classes
based only on the classfiles (i.e. without having to parse the source Java
code, which is much more difficult).

Whether you think that's worthwhile is up to you (it makes it impossible to use
the constants as "case" values in a switch, for instance). I doubt if hiding
the constants behind "accessors" has any other benefit.

-- chris

 

[Wibble]

I'm they guy who sweeps up after the elephant. My current system
has 4000 classes, with an average of 4 (conservative)
accessors per class or 16000 lines of code hidden in accessors.

Theres not a lower percentage of bugs in the accessors then
in other code, IMHO. I've had to fix alot mistypings and
cut and paster errors, and refactoring errors in accessors.

I find that if I hand write them, I make a suprisingly high
number of mistakes there too.

 

[Patricia Shanahan]

I'm they guy who sweeps up after the elephant. My
current system has 4000 classes, with an average of 4
(conservative) accessors per class or 16000 lines of code
hidden in accessors.

Theres not a lower percentage of bugs in the accessors
then in other code, IMHO. I've had to fix alot
mistypings and cut and paster errors, and refactoring
errors in accessors.

I find that if I hand write them, I make a suprisingly
high number of mistakes there too.

I see you are also a guy who top-posts in newsgroups in
which bottom-posting is conventional, and in threads that
already contain bottom-posted material. :-(

If there is any possibility of a mistypying or a
cut-and-paste error, you are dealing with hand written
getters and setters, which I fully agree need unit tests.
If they are simple cases, and coded in the last few years, I
also think the programmer's head needs examining.

Patricia

 

[Wibble]

I like top posting Pat. I like reading top posts too. Shoot me.

I always think other programmers need thier heads examined but what
prompted you to suggest it? Hand written accesors? Everyone has
thier own wacky way of doing things. If the people around me had
more sense, they wouldn't have to pay me so much.

 

[Ross Bamford]

I like top posting Pat. I like reading top posts too. Shoot me.

Do you realise how difficult it makes it to follow discussions with you
in them?

Also, are you writing test first?

 

[Harald]

Any opinions about having an interface whose sole reason for existence
is to house some public static final const primitive values to be used
by other classes? [...]
Any thoughts on using an interface in this way vs. a class?

I would only use an interface if the values you define are strong
suggestions for use as parameters of the methods defined in the
interface. If there are no methods, I would rather go for a class.

And I would absolutely not bunch up values in a class which are not
related to each other, because

a) values not needed anymore tend to be forgotten, will not be removed
and will puzzle anyone trying to maintain the code

b) in general, code maintenance becomes harder if related entities are
spread over so many files.

Harald.

 

[.]

I like top posting Pat. I like reading top posts too. Shoot me.

Wibble, I think the complaints are because it is much easier to read the
message if everything is in a linear order. That is, everyone top posts or
everyone bottom posts. The convention has been to always bottom post.

Everyone would just like you to follow the convention as it will help them
follow what you are saying.

I, personally, couldn't care less. If you have something worth saying I'll
take the time to figure things out. If I don't think it looks interesting
I'll not bother. Additionally, I always bottom post. If I'm going to take
the time to write something, I'm going to do what I can to encourage
people to read it. Otherwise I'm just talking to myself.

Just curious, why do you always top post?

I always think other programmers need thier heads examined but what
prompted you to suggest it? Hand written accesors? Everyone has
thier own wacky way of doing things. If the people around me had
more sense, they wouldn't have to pay me so much.

I'm not sure what this is about (I didn't read the rest). I do agree that
other programmers need their heads examined. That is why I ask a lot of
questions when I don't understand someone. Most the time I find the answer
quite interesting.

 

[Chris Uppal]

I do agree that
other programmers need their heads examined. That is why I ask a lot of
questions when I don't understand someone. Most the time I find the answer
quite interesting.

Y'know, that sounds /really sinister/...

;-)

-- chris