Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #2534
| From | Lew <noone@lewscanon.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Enums: Properties vs. Methods |
| Date | 2011-03-29 14:12 -0400 |
| Organization | albasani.net |
| Message-ID | <imt7e6$kti$1@news.albasani.net> (permalink) |
| References | <2f38bb8e-9a8d-4464-ad3d-b9ce0b557219@e21g2000yqe.googlegroups.com> <imt17u$892$1@dont-email.me> |
markspace wrote:
> Robert Klemme wrote:
>> /** We use custom methods. */
>> public enum Meth {
>
>
> I agree with Lew that this second example was pretty confusing and hard to
> follow. I also think that it's difficult to predict memory usage without
> careful analysis.
In the approach with final variables, they will be as constants to the
algorithm so there's really likely to be no memory waste there. 'return
false;' requires 'false' to live somewhere, be it in the 'return' statement
directly or optimized in as a constant from the 'final' variable.
> I'd like to see a "motivating" example. What do you actually intend to use
> this for? I can't see that a general case is too interesting, except to
> disqualify the method pattern.
Maybe overridable methods in enums are suitable only for behaviors, not
attributes.
>> Then different
>> enums can have differing implementations of the method and we have an
>> instance of Strategy / State pattern.
> I don't think State works this way. Strategy ... maybe, but the use of enums
> for Strategy seems confining. I'd just use regular inheritance and classes.
> The "method pattern" for Strategy would be fine I think if it weren't
> shoe-horned into an enum.
Don't get him wrong - there are plenty of use cases for overridable methods
that are ('final'ly) implemented in each enum instance.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
Back to comp.lang.java.programmer | Next | Find similar
Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 14:12 -0400
csiph-web