Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.linkpendium.com!news.linkpendium.com!teleglobe.net!newsgate.cuhk.edu.hk!news.netfront.net!not-for-mail
From: Wanja Gayk <brixomatic@yahoo.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Enums: Properties vs. Methods
Date: Sat, 2 Apr 2011 11:23:00 +0200
Organization: Netfront http://www.netfront.net/
Lines: 97
Message-ID: <MPG.2801085a92724d6898969e@202.177.16.121>
References: <2f38bb8e-9a8d-4464-ad3d-b9ce0b557219@e21g2000yqe.googlegroups.com>
NNTP-Posting-Host: 93.130.36.100
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Trace: adenine.netfront.net 1301736233 24701 93.130.36.100 (2 Apr 2011 09:23:53 GMT)
X-Complaints-To: news@netfront.net
NNTP-Posting-Date: Sat, 2 Apr 2011 09:23:53 +0000 (UTC)
User-Agent: MicroPlanet-Gravity/3.0.4
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2733

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.

Regarding the use of boolean parameters I have, some time ago written, a 
blog you might like to read:
http://brixomatic.wordpress.com/2010/02/24/boolean-harmful/

Kind regards,
-Wanja-

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---