Please rethink extended enums inclusion

[Jose Antonio Illescas Del Olmo]

On 07/10/2011 16:20, Tom Hawtin wrote:
> 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?

Tom, this is an error on my example (setCode must be private), sorry

> 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
>
>