Act 1: In support of the pessimist
==
- Fred:
- So, I’ve made this thing for you
- Bob:
- Cool! What’s that tube for – and why the electrodes?
- Fred:
- Don’t worry about that, have a play…
- Bob:
- Cool, now – what does this do? Oh, and if I poke a stick there, put my finger there, then stick my tongue in the power socket…*ouch*!
- Fred:
- Dammit! That’s not how you’re supposed to use it! I’ll never get that out of the carpet now….
==
Act 2: In support of the optimist
==
- Fred:
- So, I’ve made this thing for you
- Bob:
- Cool! Who all the lights? And what’s with the government warning label?
- Fred:
- Don’t worry about that, have a play…
- Bob:
- Hmm, so – oh, hang on, if I take this flange, and stick it _there_, then I can add my toaster here, and hey presto!
- Fred:
- Wow! I never thought of that…can I have a go?
==
And the moral is…
Those who make use @final@ for classes and methods, more often than not, believe most of the people around them (and sometimes themselves) are like Bob in Act One. I tend to to hope people like Bob in Act Two will use my code, and will worry about steam cleaning the carpet later (if by then I even own it, which more often than not, I don’t). Anyway, this will be my _final_ word on @final@, interesting comments not withstanding.
(You can find more on my views on final in “this earlier post(final – just say no?)”:http://www.magpiebrain.com/archives/2004/06/13/final, or in “comments(Use Final Wherever You Can!)”:http://rickyclarkson.blog-city.com/read/869052.htm over at Ricky Clarkson’s blog).
magpiebrain 
2 Responses to “magpiebrain theatre presents, A story of Final”
I habitually use as a phone screen question the definitions of final, finally, and finalize(), and ask for an engineering justification of when you would use each one. It gives a good clue as to whether someone who puts “five years of Java experience” on their resume’ has ever actually coded a line of it. Maximal points on the “engineering use of final” is given for “in the case of methods or classes: never, it’s useless”.
Summary: Use final because it makes the code easier to change!
I think the real issue is: how can code remain
changeable/extendable and yet retain the understandability goodness that final often provides.
Saying one should not use final as it reduces the ways in the which the code can be extended sounds like up front design to me. If one has taken the stance that users of the code will not or cannot change the code then of course this design needs to occur, but omitting final isn’t the end of it. Just because a piece of code does not contain final does not mean it will be extensible, it just makes it a little more likely.
I think if one takes the stance that users of the code can and will change it then one doesn’t need to design up front, one doesn’t need to predict the future.
Therefore one can leave the code expressing what it does now, rather than what it might do tomorrow. This naturally makes the code easier to understand.
Ironically this makes the code easier to change.