Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9119

Re: Enum mixin?

Show all headers | View raw

Robert Klemme wrote:
> markspace wrote:
>> Robert Klemme wrote:
>>> A. W. Dunstan wrote:
>>>> I'm ok with leaving it the way it is, but does anyone know of a better
>>>> approach? Preferably one that's not so complex that it's worse than my
>>>> current state of affairs?

Your current state of affairs is not that bad.  The problem is your prejudice against copy-and-paste.  There is no technical solution for that; you just have to get over it.

>>> I don't think it gets any better. Even if you go away from enums and
>>> create an abstract base class etc. you'll have to do the typing for the
>>> values plus you need to take care of serialization etc.
>>
>> I would have thought that an abstract base class would get you what you
>> need. Maybe I'm overlooking something. The second class here seems to
>> remove a lot of boilerplate, esp considering my IDE will write the
>> constructor for me (since it's the only one available).
>
> Well, for Al's original code you would also benefit from some IDE 
> boilerplate generation.  Plus, if you rename the int property according 
> to sub class then you gain even less.

+1.  

I generally put a "human-friendly" string representation of an enum constant into it:

  FOO("foo"), 
  BIG_EFFORT("big effort"), 

The code to write a static 'fromString()' and override the 'toString()' is boilerplate.  I set all my IDEs to produce that boilerplate for me when I ask for a new enum.

>> package quicktest;
>>
>> import java.io.Serializable;
>>
>> public abstract class AbstactEnum implements Serializable {
> 
> For serialization to work like with enum (i.e. always only those 
> instances in memory that you define in the class) you need to do 
> considerably more.  That effectively will be a reimplementation of enum. 
>   Plus, it can be tricky to get concurrency right etc.  And you have the 
> drawback that you need to do it yourself.

Oh, the price of not studying /Effective Java/, by Joshua Bloch (2nd ed.) (EJ)!

'Serializable' is one of the most heavily abused Java features.  Besides the tremendous amount of work it takes to actually get it right, contrary to its apparent simplicity, you are creating a permanent public interface into the private elements of the class, as EJ points out.  You really lose flexibility to refactor the implementation if you commit to a serialization format.

>> ...
>> final class CloudModel extends AbstactEnum {
>> ...
>> }
> 
> I find that not really much less typing than the original code.  Plus, 
> it's not an enum which means you lose the immediate information which 
> for example IDE's provide when showing an icon for the type of language 
> element.

There are some major drawbacks to creating a type-safe enumeration pre-Java 5 style compared to enums.  I can conceive of rare use cases for it, though.

Using type-safe enumerations requires the programmer to be responsible for all those messy details, though, as you so aptly point out.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Enum mixin? "A. W. Dunstan" <no@spam.thanks> - 2011-10-21 17:19 -0400
  Re: Enum mixin? Robert Klemme <shortcutter@googlemail.com> - 2011-10-21 23:37 +0200
    Re: Enum mixin? markspace <-@.> - 2011-10-21 16:16 -0700
      Re: Enum mixin? Robert Klemme <shortcutter@googlemail.com> - 2011-10-23 11:44 +0200
        Re: Enum mixin? Lew <lewbloch@gmail.com> - 2011-10-23 08:45 -0700
    Re: Enum mixin? "A. W. Dunstan" <no@spam.thanks> - 2011-10-24 09:23 -0400
  Re: Enum mixin? Roedy Green <see_website@mindprod.com.invalid> - 2011-10-22 18:10 -0700

csiph-web