Re: Class Constants - pros and cons
On Jul 28, 10:45 am, Robert Klemme <shortcut...@googlemail.com> wrote:
On 25.07.2010 16:39, Lew wrote:
Magnus Warker a =E9crit :
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 ) =
)'.
That depends on the rest of Color's class definition (whether there are
public constructors, whether the class is serializable and whether
custom deserialization is in place - all stuff someone who makes this an
enum does not have to take care of manually btw). For enums (whether a=
s
language construct or properly implemented although this is a bad idea
since Java 5 IMHO) I would rather use "==" here because it is more
efficient and stands out visually.
Yeah, I was corrected on that some time upthread and already
acknowledged the error. I had it in my head that we were dicussing
String contants rather than final instances of the 'Color' class.
As for using == for enums, that is guaranteed to work by the language
and is best practice.
As for writing type-safe enumeration classes that are not enums,
there's nothing wrong with that if you are in one of those corner use
cases where Java features don't quite give you what you want. The
only one I can think of is inheritance from an enumeration. However,
I agree with you in 99.44% of cases - it's almost always bad to extend
an enumeration and Java enums pretty much always do enough to get the
job done. So when one is tempted to write a type-safe enumeration
class that is not an enum, one is almost certainly making a design
mistake and an implementation faux-pas.
One can even have custom code *per enum value* which makes implementing
state patterns a breeze.
I have not so far encountered a real-life situation where a 'switch'
on an enum value is cleaner or more desirable than using enum
polymorphism. For state machines I'm more likely to use a Map (or
EnumMap) to look up a consequent state than a switch. Have any of you
all found good use cases for a 'switch' on an enum?
--
Lew