Class Constants - pros and cons
in [Java Help]
|
From: Jean-Baptiste Nizet on 25 Jul 2010 04:51 Magnus Warker a �crit : > It's the readibility of the code. > > With constant classes I can write something like this: > > public void setColor (Color color) > { > if (color == Color.WHITE) > ... > } > > This is not possible with enums, since an enume type must be defined in a > class: > > public void setColor (SomeClass.Color color) > { > if (color == SomeClass.Color.WHITE) > ... > } > No. Read more about enums. Enums are classes, and can be top-level classes. You define them, as regular classes, in their own .java file : // Color.java package com.foo.bar; public enum Color { WHITE, BLACK; } // SomeClass.java public void setColor(Color color) { this.color = color; if (color == Color.WHITE) { // ... } switch (color) { case WHITE : // ... } } > I think, it would be ok, if I needed the enum only in SomeClass. > > But what about constants that are needed in many classes? > You define them in their own .java file > I saw that constant classes are used widely in the java api, e. g. > java.awt.PageAttributes.MediaType. But I also saw constants declared as > final ints anyway. > Yes, because enums only appeared in Java 5, and lots of classes had already been written before that, and thus used final ints or Strings instead. > Thanks > Magnus > > Peter Duniho wrote: >> Have you thought about using enums instead? If enums aren't solving >> your need, it would be helpful if you could explain why. >
From: Lew on 25 Jul 2010 10:39 Magnus Warker a écrit : Don't top-post! >> It's the readibility of the code. >> >> With constant classes I can write something like this: >> >> public void setColor (Color color) >> { >> if (color == Color.WHITE) No. That would be a bug. You'd write 'if ( color.equals( Color.WHITE ) )'. >> ... >> } >> >> This is not possible with enums, since an enume type must be defined in a >> class: >> >> public void setColor (SomeClass.Color color) >> { >> if (color == SomeClass.Color.WHITE) >> ... >> } And how is that less readable? Besides, it's wrong. 'Color' would *be* the enum, so you'd still have 'Color.WHITE', unless 'Color' were a nested class, but then it would be in the constant String scenario, too. Further besides, with an enum you wouldn't say if ( color.equals( Color.WHITE )) { foo( something ); } or if ( color == Color.WHITE ) { foo( something ); } you'd say color.foo( something ); Jean-Baptiste Nizet wrote: > No. Read more about enums. Enums are classes, and can be top-level > classes. You define them, as regular classes, in their own .java file : > > // Color.java > package com.foo.bar; > > public enum Color { > WHITE, > BLACK; > } > > // SomeClass.java > public void setColor(Color color) { > this.color = color; > if (color == Color.WHITE) { > // ... > } > switch (color) { > case WHITE : > // ... > } > } Magnus Warker a écrit : >> I think, it would be ok, if I needed the enum only in SomeClass. >> >> But what about constants that are needed in many classes? ?? Have them refer to the enum. Jean-Baptiste Nizet wrote: > You define them in their own .java file Magnus Warker a écrit : >> I saw that constant classes are used widely in the java api, e. g. >> java.awt.PageAttributes.MediaType. But I also saw constants declared as Jean-Baptiste Nizet wrote: > Yes, because enums only appeared in Java 5, and lots of classes had > already been written before that, and thus used final ints or Strings > instead. Peter Duniho wrote: >>> Have you thought about using enums instead? If enums aren't solving >>> your need, it would be helpful if you could explain why. That would still be helpful. ints and Strings are not typesafe. enums are. Use enums. If you expect a constant String 'GlueConstants.CHOIX' equal to "foobar" and pass 'ShoeConstants.CHOIX' equal to "fubar" instead, the compiler won't complain. If you pass the wrong enum it will. Since enums are classes, they can contain behavior. That means you won't need if-chains nor case constructs to select behavior; just invoke the method directly from the enum constant itself and voilà! -- Lew Don't quote sigs, such as this one, either.
From: jebblue on 25 Jul 2010 12:47 On Sun, 25 Jul 2010 10:39:33 -0400, Lew wrote: > Further besides, with an enum you wouldn't say > if ( color.equals( Color.WHITE )) > { > foo( something ); > } > or > if ( color == Color.WHITE ) > { > foo( something ); > } > you'd say > color.foo( something ); > Since enums are classes, they can contain behavior. That means you > won't need if-chains nor case constructs to select behavior; just invoke > the method directly from the enum constant itself and voilà! Sometimes I use plain enums with no specific value assigned to the elements and sometimes I add a getter, getValue() to enable specific values but I don't extend an enum (from an OOP perspective) beyond acting as an enum. If foo() has no relationship to color, and bar() and stuff() also need to execute when color.equals(Color.WHITE)); why extend an enum to be more than it needs to be? That's what a regular class is for. Sorry if I may have missed your point. -- // This is my opinion.
From: Joshua Cranmer on 25 Jul 2010 12:52 On 07/25/2010 10:39 AM, Lew wrote: >>> It's the readibility of the code. >>> >>> With constant classes I can write something like this: >>> >>> public void setColor (Color color) >>> { >>> if (color == Color.WHITE) > > No. That would be a bug. You'd write 'if ( color.equals( Color.WHITE ) )'. To be pedantic, it would not be a bug if the Color class were written in a certain way, i.e., there is no other Color instances other than those in Color's static instance variables. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Lew on 25 Jul 2010 15:03
Magnus Warker wrote: >>>> It's the readibility of the code. >>>> >>>> With constant classes I can write something like this: >>>> >>>> public void setColor (Color color) >>>> { >>>> if (color == Color.WHITE) Lew wrote: >> No. That would be a bug. You'd write >> 'if ( color.equals( Color.WHITE ) )'. Joshua Cranmer wrote: > To be pedantic, it would not be a bug if the Color class were written in > a certain way, i.e., there is no other Color instances other than those > in Color's static instance variables. You are wrong, this once. (In your case, an extremely rare occurrence.) It's impossible to enforce that for all clients 'color' is assigned the exact instance, therefore that == will work if the static variables are Strings. It's all too easy to accidentally push in a different constant String from some other class, as outlined in my other response, or by other means to create a different instance of a String that you intend even with the correct value. So yes, to be pedantic, using == would be a bug waiting to happen, as would using String constants when enum constants are so much safer (and guaranteed to work with == ). -- Lew |