Please rethink extended enums inclusion

[Tom Hawtin]

On 07/10/2011 14:34, Jose Antonio Illescas Del Olmo wrote:
> On 07/10/2011 14:38, Tom Hawtin wrote:
>> On 07/10/2011 12:34, Jose Antonio Illescas Del Olmo wrote:
>>> Now we have hundred of enums on our project (finantial application with
>>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>>        public enum Type {
>> [...]
>>>           public void setCode(String code) {
>>>               this.code = code;
>> I have to point out that mutable enums, or other statics, is generally a
>> *really* bad idea. (Also a non-null check here wouldn't go amiss.)
>>
> Sorry, I don't understand you. Where is the mutable enums that you say?

The `Type` enum is mutable. You can set the code field. Instances of 
enums are statics. Mutable statics are bad, and so therefore are mutable 
enums (and singletons). Plenty has been written about this. In the olden 
days, the same thing went under the heading of "globals".

http://www.google.co.uk/search?q=java+"mutable+enums"
http://www.google.co.uk/search?q=java+"mutable+statics"

>>    Just introduce a class
>> that contains the mapping, and add an instance to each enum. You may
>> need to implement a one-method interface if you want to initialise the
>> mappings from MyEnum.values().
>
> But one additional class for every enum (exist more than 350 enums on my
> application) add to many code to map code-enum (I like to remove
> unnecesar code)

No, just a single class with one instance per enum. That isn't much.

Tom