Re: Class Constants - pros and cons
On 07/28/2010 06:13 PM, Lew wrote:
On Jul 28, 10:45 am, Robert Klemme<shortcut...@googlemail.com> wrote:
On 25.07.2010 16:39, Lew wrote:
Magnus Warker a =E9crit :
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 ar=
e
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 =
as
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.
I hadn't made it through all branches of the thread. I should have read =
to the end before posting. Sorry for the additional noise.
As for using == for enums, that is guaranteed to work by the langua=
ge
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 implementin=
g
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?
Personally I cannot remember a switched usage of enum, The only reasons =
to do it that come to mind right now are laziness and special
environments (e.g. where you must reduce the number of classes defined
for resource reasons, maybe Java mobile). But then again, you would
probably rather use ints instead of an enum type...
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/