What is the reason for putting constants in another class?

Thread view:

- - 06 May 2005 02:01 GMT

Does anybody know the reason why the constants in
javax.swing.ScrollPaneConstants are put in a separate class instead of
simply putting them inside javax.swing.JScrollPane itself?

Reply to this Message

Joseph Dionne - 06 May 2005 02:12 GMT

> Does anybody know the reason why the constants in
> javax.swing.ScrollPaneConstants are put in a separate class instead of
> simply putting them inside javax.swing.JScrollPane itself?

They are all gouged in one place, typically public static final, and
accessed as MyClassDefaults.CONSTANT_VALUE.

Reply to this Message

- - 06 May 2005 02:23 GMT

>> Does anybody know the reason why the constants in
>> javax.swing.ScrollPaneConstants are put in a separate class instead of
>> simply putting them inside javax.swing.JScrollPane itself?
>
> They are all gouged in one place, typically public static final, and
> accessed as MyClassDefaults.CONSTANT_VALUE.

Then how about the constants in java.awt.event.ActionEvent? Why didn't
they put them in ActionEventConstants? Is it because they only make it
a point to separate them from swing onwards?

Reply to this Message

Joseph Dionne - 06 May 2005 02:59 GMT

>>> Does anybody know the reason why the constants in
>>> javax.swing.ScrollPaneConstants are put in a separate class instead
[quoted text clipped - 6 lines]
> they put them in ActionEventConstants? Is it because they only make it
> a point to separate them from swing onwards?

Perhaps Java is showing its age? As use in a language increases,
drawing greater feed back, "proper" syntax evolves addressing common
complaints. But, Java tries to be "upwards" portable. Changing AWT at
1.3 or later would break every application developed prior. That is
what Microsoft does with annoying regularity. Sun changes API structure
breaking upward compatibility, i.e. depreciated notices, but gives
developers time to update source code while allowing them up use new
features in new product.

Joseph

Reply to this Message

Daniel Sjöblom - 06 May 2005 03:21 GMT

> Does anybody know the reason why the constants in
> javax.swing.ScrollPaneConstants are put in a separate class instead of
> simply putting them inside javax.swing.JScrollPane itself?

In this particular case, notice that ScrollPaneConstants is an
interface. Thus, by implementing ScrollPaneConstants in a class one can
write MY_FOO_CONSTANT instead of ScrollPaneConstants.MY_FOO_CONSTANT to
refer to some variable. In java 1.5, there is a facility called static
import that allows one to omit the class name without resorting to this
hack.

Signature

Daniel Sjöblom
Remove _NOSPAM to reply by mail

Reply to this Message

Andrew McDonagh - 06 May 2005 08:18 GMT

>> Does anybody know the reason why the constants in
>> javax.swing.ScrollPaneConstants are put in a separate class instead of
[quoted text clipped - 6 lines]
> import that allows one to omit the class name without resorting to this
> hack.

And yet we should keep in mind that interfaces that define constants,
has been shown to be an anti-pattern.

Reply to this Message

Wibble - 07 May 2005 03:11 GMT

I hate this pattern. You put a pile of constants
in a class, use them globally, all the consumers
refactor away and you end up with a file full of
things nobody uses or knows what they're for, but
everyone is afraid to touch.

>>> Does anybody know the reason why the constants in
>>> javax.swing.ScrollPaneConstants are put in a separate class instead
[quoted text clipped - 9 lines]
> And yet we should keep in mind that interfaces that define constants,
> has been shown to be an anti-pattern.

Reply to this Message

What is the reason for putting constants in another class?

Free Magazines