Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Enums: Properties vs. Methods
Date: Wed, 30 Mar 2011 20:06:13 +0200
Lines: 51
Message-ID: <8vh9p1FikeU1@mid.individual.net>
References: <2f38bb8e-9a8d-4464-ad3d-b9ce0b557219@e21g2000yqe.googlegroups.com> <imt17u$892$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net Z9zx48tKAWUfkb9teFEQfA3kpt6A2ovIiNLYUty6pcQFLB0U4=
Cancel-Lock: sha1:+PDtdL3VNGdrH+w+el6TrW/w0gQ=
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
In-Reply-To: <imt17u$892$1@dont-email.me>
X-Antivirus: avast! (VPS 110330-0, 30.03.2011), Outbound message
X-Antivirus-Status: Clean
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2602

On 29.03.2011 18:26, markspace wrote:
> On 3/29/2011 8:18 AM, Robert Klemme wrote:
>> /** We use custom methods. */
>> public enum Meth {
>
> I agree with Lew that this second example was pretty confusing and hard
> to follow. I also think that it's difficult to predict memory usage
> without careful analysis.
>
> I'd like to see a "motivating" example. What do you actually intend to
> use this for? I can't see that a general case is too interesting, except
> to disqualify the method pattern.

See https://gist.github.com/892503#file_valve.java

>> Then different
>> enums can have differing implementations of the method and we have an
>> instance of Strategy / State pattern.
>
> I don't think State works this way. Strategy ... maybe, but the use of
> enums for Strategy seems confining. I'd just use regular inheritance and
> classes. The "method pattern" for Strategy would be fine I think if it
> weren't shoe-horned into an enum.

Actually I always have a hard time distinguishing those two patterns: 
IMHO they are pretty much identical at the core, the main feature is 
that I delegate functionality to another instance which might be from 
different classes related via inheritance (at least implementing the 
same interface).  The only real difference that I can spot is the point 
in time when the delegate is changed: in one case it might be never 
changed during the lifetime of an instance (strateg) and in the other 
case it is changed whenever a state change occurs (state).  I find that 
only a marginal difference between the two compared to the crucial point 
that those patterns both use an exchangeable delegate.

http://en.wikipedia.org/wiki/State_pattern
http://en.wikipedia.org/wiki/Strategy_pattern

>> Full toy class https://gist.github.com/892503#file_prop_vs_meth.java
>
> I'll check it out.

Thanks.

Kind regards

	robert

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