Re: Usefulness of "final" (Was: Re: Inserting In a List)
On 03/04/13 18:08, Robert Klemme wrote:
On 03.04.2013 12:15, lipska the kat wrote:
On 02/04/13 20:06, Robert Klemme wrote:
On 04/02/2013 04:08 PM, lipska the kat wrote:
Just as a matter of interest what's with all the finals
particularly
for (final File name : folder.listFiles())
[snip]
I believe in using "final" pretty often as it will immediately indicate
which local variables are constant for a method call and which are
modified all the time. Plus, with "final" you can easier catch errors
in control flow:
final String x;
if ( someCondition() ) {
x = y.toString();
}
else {
if ( someOtherCondition() ) {
x = "foo";
}
// forgot the else branch here
x = "bar";
}
System.out.println("We got " + x);
Generally I find "finally" quite useful - apparently significantly more
useful than you do. :-)
Well I'm not sure that using a storage class to help you write a
conditional statement is 'good programming style' but hey ho, different
strokes for different folks :-)
I am not sure what you mean by that. Can you elaborate? Where's the
storage class in the example above?
final, although it's not is it, at least it's not Java terminology,
apologies, I should have said 'modifier'. I'll restate.
Well I'm not sure that using a modifier to help you write a
conditional statement is 'good programming style'. When I see the
modifier final it says something to me, it says, this value is not
modifiable ('scuse the pun). Is it improving the clarity of your code to
use final for it's side effect, that is the side effect of causing the
compiler to barf because a final variable may already have been
initialized. I'm not sure about that.
Anyway, the usability of final depends on your point of view I suppose.
We can certainly agree on *that*.
If for some reason I find myself using 'final' all over the place then I
would have to ask myself if my abstraction was coherent. If one has
something, or in fact a number of somethings that need 'protecting' in
this way then surely it is better to wrap them up in a component and
control access by virtue of the public interface of that component.
It probably depends. Sometimes you want to hold on to something because
obtaining it is expensive or the accessor might return a changed version
during subsequent calls but you want to be sure to retain a specific
status. In those cases I would not think that wrapping it up
necessarily helps because the data may actually have been wrapped
already. It feels a bit over the top introducing another layer just to
avoid a local variable with "final".
For a single local variable I'd probably agree, in fact in general I
would agree but that wasn't my initial point really, in the code that
kicked off this sub thread there was more than one final variable, in
fact there were several in close proximity, I was initially questioning
the clarity of this for a new user. However then I opened my mouth and
put my foot in it and said ...
It's more OO, makes for cleaner code and of course provides opportunity
for the holy grail of OO 're-usability'
Maybe I could better see (and agree) if you provide a specific example
of what you mean here.
I think you probably know what I mean and any off the cuff example will
be contrived to the point irrelevance, so, leave it with me and I'll see
if I can come up with a simple self contained example.
lipska
--
Lipska the Kat?: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun