magpiebrain theatre presents, A story of Final
Act 1: In support of the pessimist
<dl> <dt>Fred:</dt><dd>So, I’ve made this thing for you</dd> <dt>Bob:</dt><dd> Cool! What’s that tube for - and why the electrodes?</dd> <dt>Fred: </dt><dd>Don’t worry about that, have a play…</dd> <dt>Bob: </dt><dd>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*!</dd> <dt>Fred: </dt><dd>Dammit! That’s not how you’re supposed to use it! I’ll never get that out of the carpet now….</dd> </dl> >Act 2: In support of the optimist
<dl>
<dt>Fred: <dt><dd>So, I’ve made this thing for you</dd>
<dt>Bob:</dt><dd> Cool! Who all the lights? And what’s with the government warning label?</dd>
<dt>Fred: </dt><dd>Don’t worry about that, have a play…</dd>
<dt>Bob: </dt><dd>Hmm, so - oh, hang on, if I take this flange, and stick it _there_, then I can add my toaster here, and hey presto!</dd>
<dt>Fred:</dt><dd>Wow! I never thought of that…can I have a go?</dd>
</dl>
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.
, or in comments over at Ricky Clarkson’s blog).
This entry was posted on Thursday, October 21st, 2004 at 5:47 pm and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
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.
Have your say
Fields in bold are required. Email addresses are never published or distributed.
Some HTML code is allowed:
URIs must be fully qualified (eg: http://www.domainname.com) and all tags must be properly closed.
Line breaks and paragraphs are automatically converted.
Please keep comments relevant. Off-topic, offensive or inappropriate comments may be edited or removed.