Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Enums: Properties vs. Methods

Reply
Thread Tools

Enums: Properties vs. Methods

 
 
Robert Klemme
Guest
Posts: n/a
 
      04-02-2011
On 01.04.2011 04:16, Lew wrote:
> Robert Klemme wrote:
>> Lew wrote:
>>> Start here: JLS, 17.5.3, as I cited earlier.

>>
>> It seems that is not a good place to start (see other postings).

>
> Indeed.


What now?

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      04-02-2011
Robert Klemme wrote:
> Lew wrote:
>> Robert Klemme wrote:
>>> Lew wrote:
>>>> Start here: JLS, §17.5.3, as I cited earlier.
>>>
>>> It seems that is not a good place to start (see other postings).

>>
>> Indeed.

>
> What now?


Do you mean how do we distinguish the two alternatives now?

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      04-02-2011
On 04/02/2011 05:23 AM, Wanja Gayk wrote:
> In article<2f38bb8e-9a8d-4464-ad3d-b9ce0b557219
> @e21g2000yqe.googlegroups.com>, http://www.velocityreviews.com/forums/(E-Mail Removed) 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 {
> //@formatterff
> 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;}
> }
> ;
> //@formattern
>
> 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/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      04-03-2011
On 02.04.2011 16:29, Lew wrote:
> Robert Klemme wrote:
>> Lew wrote:
>>> Robert Klemme wrote:
>>>> Lew wrote:
>>>>> Start here: JLS, 17.5.3, as I cited earlier.
>>>>
>>>> It seems that is not a good place to start (see other postings).
>>>
>>> Indeed.

>>
>> What now?

>
> Do you mean how do we distinguish the two alternatives now?


I rather meant what is the assessment of the community about possible
optimizations applied by the JVM to both approaches? My personal
opinion at this point is that the "properties" approach might be more
efficient since getter methods can be inlined (there is just one class
so there are not multiple variants for e.isOpen() as opposed to having
different classes).

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is there a way to find the class methods of a class, just like'methods' finds the instance methods? Kenneth McDonald Ruby 5 09-26-2008 03:09 PM
CompositeControls: ViewState properties w/ Mapped properties probl =?Utf-8?B?Q2hyaXN0b3BoZSBQZWlsbGV0?= ASP .Net 1 01-19-2006 09:19 AM
Making Custom Control Properties Visible in Visual Studio's Properties Palette Nathan Sokalski ASP .Net 0 10-17-2005 02:05 AM
Re: C++ properties Library Created (was Binding together Properties of Objects) Victor Porton C++ 1 08-29-2004 08:02 PM
Problems parsing when Properties.dtd.properties Kent Lichty Java 0 04-16-2004 03:08 PM



Advertisments