Comments on: magpiebrain theatre presents, A story of Final http://www.magpiebrain.com/blog/2004/10/21/magpiebrain-theatre-presents-a-story-of-final/ Sam Newman's blog Sat, 05 Jul 2008 00:46:59 +0000 http://wordpress.org/?v=2.5.1 By: Stacy Curl http://www.magpiebrain.com/blog/2004/10/21/magpiebrain-theatre-presents-a-story-of-final/#comment-556 Stacy Curl Wed, 03 Nov 2004 10:20:39 +0000 http://www.magpiebrain.com/2004/10/21/magpiebrain-theatre-presents-a-story-of-final/#comment-556 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. 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.

]]> By: dave http://www.magpiebrain.com/blog/2004/10/21/magpiebrain-theatre-presents-a-story-of-final/#comment-555 dave Thu, 21 Oct 2004 20:40:15 +0000 http://www.magpiebrain.com/2004/10/21/magpiebrain-theatre-presents-a-story-of-final/#comment-555 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". 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”.

]]>