Re: final and constructor, a Java Wart
Arne Vajh??j wrote:
Roedy Green wrote:
Lets say you noticed that your constructor was getting overweight, and
decided to split it into more manageable chunks.
All of a sudden all your finals on the instance variable become
ERRORS!!!
The is correct because in THEORY someone later could call one of your
dependent methods.
So you remove your finals.
This is NOT a good thing.
It makes it look as though these are NOT final to other programmers.
You take off your safety wheels protecting you from duplicate
assignment or inadvertent assignment.
Wrong answer. Leave 'final' on the variables and don't use dependent methods
to assign them. Use an instance initializer.
I have never liked the "final on everything possible" approach.
Code clutter in my opinion.
I agree, but there is a strong use case for using 'final' a lot. Any instance
or static member variable that should not be changed should be 'final'. It is
not code clutter because it invokes compiler assistance to enforce
immutability, it changes the semantics of initialization in your favor and it
guarantees thread safety.
Strong benefits for what you disparagingly deem "code clutter".
Accidentally assigning to something that should not be changed
is not a common problem.
Oh, yes, it is. I have run into it many times in production code. Even
worse, failure to properly synchronize access to unchanging but non-final
variables between threads is fairly common, and inordinately disastrous when
it occurs. The result isn't multiple assignment but failure to assign, from
some thread's point of view. The mathematical expectation, likelihood times
cost, is large.
--
Lew