Re: Enums: Properties vs. Methods
On 29.03.2011 17:47, Lew wrote:
On 03/29/2011 11:18 AM, Robert Klemme wrote:
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
How is that a pro?
The reasoning was that then less space in Perm is needed.
- when adding enum values to an enum you cannot forget to define
properties
pro Methods:
- smaller memory footprint per instance
You actually don't know what the footprint will be once Hotspot takes
over. With your "toy" example, those booleans might all optimize away
and both cases take the same memory at runtime.
Just so I understand it properly: are you saying that with hotspot the
compiler might remove members of the instances? I am not sure how that
would work since then hotspot would need to create several different
versions of the property getter methods (one per instance). I believe
this is not what hotspot can do.
Considering that there are always only so many instances it seems the
properties approach wins. It seems, custom methods in enum instances
are most useful if enums do actually do something. Then different
enums can have differing implementations of the method and we have an
instance of Strategy / State pattern.
Do you have more items for the lists? Did I overlook something?
Your example didn't make a good case for why you'd want do do such a thing.
Right.
Your "methods" example is confusing and the purpose behind the logic
deeply obscured by the idioms. That alone is enough to kill it. Your
"properties" example was clear and concise and easy to follow.
No-brainer.
Well, roughly speaking the idea was this:
https://gist.github.com/892503#file_valve.java
Here there are boolean properties which derive from the enum, i.e.
whether there is traffic allowed or not and whether the traffic can flow
unlimited.
Now code which uses this enum need not create switches based on concrete
enum instances but can use boolean properties in control flow (e.g.
print a warning if no traffic at all is allowed). One might later want
to add another enum value BROKEN(false, false) which is used to describe
the state of a broken medium. If this is done the code that uses those
properties to make decisions does not need to be extended.
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/