Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Enums: Properties vs. Methods Date: Tue, 29 Mar 2011 14:12:28 -0400 Organization: albasani.net Lines: 38 Message-ID: References: <2f38bb8e-9a8d-4464-ad3d-b9ce0b557219@e21g2000yqe.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net gM0F7VlugzBDfPFilBDtSoZ2O2iewq6GtFrwfzQrDB8PUk4wFYRGU6jYBmunXcoUqrcvU25/HjpOoNvxa8YIgslUZLoWjIlcZpUidpbHqeYp4UL8/U6Ean9iAUHbiOem NNTP-Posting-Date: Tue, 29 Mar 2011 18:12:22 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="B0kaAP9j6bjMw43n9wRhu6iYGHzUY6qI1IVgDRwKcCgomBZShm5GY4G7Cpvh6o+DVnRLbCspvtEoczN7bOXqwGxfwmXLfmer4OUqIj1sQ15cy8F+eEw9iwZNxH5WHjkK"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: Cancel-Lock: sha1:J1Fxh/ipCViq8nMwsR35kCJRdvA= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2534 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