Opinion: Final should be default, not deprecated

Posted by Floyd Marinescu on May 31, 2006

Sections

Development,

Architecture & Design

Topics

Java ,

Programming

Tags

Language Features ,

Languages

Elliotte Rusty Harold has joined a growing discussion across some blogs and lists about the topic of deprecating the final keyword in Java, saying that final should be 'default' unless explicitly marked otherwise, at least for methods. According to Elliotte (from an earlier post), the lack of finality has created a huge, brittle, dangerously breakable infrastructure in the world of Java class libraries.

Elliotte starts off putting design by contract in context to inheritance, saying that the the subclasses must maintain the class invariants and postconditions of their superclasses.   Subclasses can relax a parent classes preconditions but not over ride them, as that would make it impossible to guarantee the behavior of the sub classes.  Therefore, "it follows that most methods should be fina ...Failing to mark them final risks postcondition, precondition, and class invariant violation."

So Final should not be deprecated, but used all the time, UNTIL Java the language could be modified, in order to:

make preconditions, postconditions, and class invariants language level constructs. Then make them automatically inherited by all subclasses. This would allow subclasses to override methods from the superclass, but would not allow them to change the superclass’s defined behavior. They could only change things the superclass did not explicitly promise.

They’re a lot of other benefits to this scheme as well. First of all it would mean more people would use design by contract, and thus write better code. For those of us who already use design by contract, it would make our code much simpler. But what interests me for the moment is that it would dramatically reduce the need for final. final is really overkill for 90% of the uses to which it’s put.

Elliotte concludes his entry criticizing the over-use of Interfaces:

They’re a lot of high-powered theorists who just love interfaces and abstract factories; and it’s not a coincidence that these are the same people who hate final. They’re wrong about this too, and for the same reason. Java interfaces have no ability to enforce preconditions, postconditions, and invariants. This means they’re appropriate only when a type really doesn’t have any of those, which is rare.

1. Back to top

   Final is valuable

   by Rod Johnson

   I agree that the final keyword is a powerful mechanism for maintaining class invariants, and is under-used in many codebases.

   Reply

2. Back to top

   Extension mechanism

   by Rod Johnson

   Hand-in-hand with that is the fact that (in my experience, anyway) subclassing and overriding methods is not the right way to extend functionality in most cases. Composition is usually better than inheritance, and patterns such as the Strategy pattern usually offer much better extensibility without the need to risk class invariants.

   Reply

3. Back to top

   Re: Extension mechanism

   by Corby Page

   Hmmm... wanted to make a point here, but I can't find a code formatter that makes Java look legible in the message text.

   Reply

4. Back to top

   Re: Extension mechanism

   by Michael Hunger

   I don't agree. When overusing the final keyword you force developers who use your codebase to reinvent the wheel or copy your classes to slightly extend them.
   When used with delegation/composition the same fact applies to the delegate used. Mostly it is a implementing class of an interface or a subclass of an abstract or default implementation. When only allowing the methods you think of being worth to be overridden you restrict the possibilities.
   Just today I had to copy the code of NameMatchTransactionAttributeSource as there were no protected methods to be overridden that allow the modification of the matching algorithm (i.e. the access of the map set as property).
   I fully agree when using the final keyword on method parameters, local and global variables that should be fixed and reduce the possibility of coding errors. (Trade semantic errors for compiler errors - see Hardcore Java by Robert Simmons).
   
   Michael

   Reply

5. Back to top

   Is it testable?

   by leonardo susatyo

   The point that the author missed was the fact some of the problems of making classes/methods finals is they tend to be very hard to test.
   
   Obviously, I agree with the author's points of invariants, etc. But the way I usually enforce invariants are through unit testings. And nothing makes me happier than to have a well designed class resulting from unit testings. TDD anyone?

   Reply

6. Back to top

   Re: Final is valuable

   by Lars Stitz

   I agree with you, but I think that both proposals -- deprecating the final keyword, or making it a default setting -- are just trying to cover up symptoms, instead of solving the real problem.
   
   The real problem as I perceive it is education. Many Java developers simply don't know when to use the keywords final, volatile or even synchronized and transient. Hell, I even keep seeing completely abstract classes where an interface would have done the job nicely.
   
   The final keyword is definitely a good thing in the Java language. But if a programmer is unable to master that features, only a fool would blame the feature...
   
   Just my 2 cents, Lars

   Reply

7. Back to top

   Re: Extension mechanism

   by Lars Stitz

   I guess nobody is seriously questioning that the overuse of anything is dangerous. Same can be said for food, for instance. Or for the private keyword, for that matter -- as I always have to acknowledge grudgingly when programming Swing.
   
   The funny thing, though, is that you never notice the "overuse" of private or final in your own software, but only in third party frameworks... ;-)
   
   Cheers, Lars

   Reply

8. Back to top

   Re: Extension mechanism

   by Marc Logemann

   final is the most undervalued keyword in java. I can only fully agree to Elliot here. When certain people say it should be deprecated, i wonder how they develop programs at all.
   
   Not using final means taking the risk of inproper API usage, resulting in various problems when using APIs in general.
   
   Marc Logemann

   Reply

9. Back to top

   Re: Extension mechanism

   by Sam Corder

   I've always believed that the best written software is used (successfully) for purposes that the author did not intend. For instance the original browser and html were not intended for e-commerce. I think the same should hold true for libraries. I think using final by default makes this hard unless you have been able to predict every possible extension point and use. People here seem to worry about someone creating a subclass that breaks some contract and makes the code behave erratically. That is that coders problem not the original author. They need to write correct code and it isn't my job to make sure that they do it.

   Reply

10. Back to top

    Re: Final is valuable

    by Rod Johnson

    Lars
    
    

    I agree with you, but I think that both proposals -- deprecating the final keyword, or making it a default setting -- are just trying to cover up symptoms, instead of solving the real problem.

    
    Both proposals are quite extreme. The language presently offers a good tool that developers can choose to use.
    
    

    The real problem as I perceive it is education.

    
    Exactly. The problem is not the language, it's lack of knowledge of some very important features.
    
    Rgds
    Rod

    Reply

• Older >