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.
is together and nothing is public that is much less of a confusion. For that
Honi soit qui mal y pense.