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: Sat, 02 Apr 2011 10:36:44 -0400 Organization: albasani.net Lines: 92 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 v3b0gOO2xFFnXM4XbYaLrc42+hyqRruaMfqpQJEm5aHKmvNxrZX0gvENykORdb2CoNlXnQTSon6TUV98hGuj2g== NNTP-Posting-Date: Sat, 2 Apr 2011 14:36:41 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="IhxG9bA0grYG3eMHtVnzxFTZyNQUCIN3elMCDHVSv16IiOuod7tF+urkDU23HvKb7dqL5FkE8VTkJnZbXi/qKasR/YLCJtZVJAG7NCIUxRTN8JJG0h3uN3m87YtWgQ76"; 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:T8yPrHz8SX8czrGtv9nzo1z0L2M= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2752 On 04/02/2011 05:23 AM, Wanja Gayk wrote: > In article<2f38bb8e-9a8d-4464-ad3d-b9ce0b557219 > @e21g2000yqe.googlegroups.com>, shortcutter@googlemail.com says... >> >> All, >> >> I am just musing about the pros and cons of using boolean properties >> in enum classes vs. custom methods. >> So far I found >> >> pro Properties: >> - less classes >> - when adding enum values to an enum you cannot forget to define >> properties >> >> pro Methods: >> - smaller memory footprint per instance > > Quite frankly: Use what's easier to read and maintain. > Memory and runtime should be your smallest concern, assuming you use > some common sense when chosing your algorithm, only if there's clearly a > problem for the user and the system you should optimize to something > probably less readable. To find bottlenecks, don't guess, but use a > profiling tool. "jvisualvm" (which you can find in your jdk/bin folder) > is not bad for a start. > >> Example >> /** We use boolean properties. */ >> public enum Prop { >> >> A(true, true), B(true, false), C(false, true); >> >> private final boolean a; >> >> private final boolean b; >> >> Prop(boolean a, boolean b) { >> this.a = a; >> this.b = b; >> } >> >> public boolean isA() { >> return a; >> } >> >> public boolean isB() { >> return b; >> } >> } > > Like proposed elsewhere you could also write (untested): > > public enum Prop { > //@formatter:off > A(){ > public boolean isA(){return true;} > public boolean isB(){return true;} > > }, > B(){ > public boolean isA(){return true;} > public boolean isB(){return false;} > }, > C(){ > public boolean isA(){return false;} > public boolean isB(){return true;} > } > ; > //@formatter:on > > public abstract boolean isA(); > public abstract boolean isB(); > } > > > Consider that the use of boolean parameters is often quite bad to read > and maintain. Just have a look at your boolean initializer: > > A(true, true), B(true, false), C(false, true); > > You can't tell from looking at the code, whether the first argument > represents the return value for "isA" or "isB". From this point of view, > with a proper formatting, I'd prefer the abstract method approach. I get your point about the parameter approach, but in an enum where everything is together and nothing is public that is much less of a confusion. For that I'd go with the first form for clarity and simplicity. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg