final class vs final methods

[anish jain]

what is the difference between making a class final and making all the methods of that class final?

Also tell me the scenario when either of those has to be used.

I am a bit confused in that..

could anybody please help me?

[Satya Maheshwari]

I found this link useful for this query:

http://www.roseindia.net/javatutorials/final_methods.shtml

[Rob Spoor]

If only the methods are final you can still extend the class, just not override those methods. If the class is final you can't even extend the class (therefore also not override its methods).

[anish jain]

Satya Maheshwari wrote:I found this link useful for this query:

http://www.roseindia.net/javatutorials/final_methods.shtml

It's quite a knowledgeable information..but still it doesn't solve my confusion..

What i understood from the above link is that making a method final will improve the performance a bit..
so does it mean that we don't need to make the class final..And we all know that String class is final so why is it so?

please help

[Ninad Kulkarni]

@anish
Rob already given the answer to your question. To make a class final is depend on requirement.

[Ralph Cook]

A final class cannot be extended.

A final method cannot be overridden.

If you made all the methods in a class final, you could still extend the class; an object of this subclass could then be used in places where the superclass could be used, but the subclass could still have additional methods that the superclass did not have. The subclass could not, however, modify the behavior of the superclass methods at all, not even in ways that would make sense in terms of the subclassing.

I don't know why String is overridden, particularly; I always expected that, because it is bound to be used so extensively in programs, perhaps performance was judged to be an issue there, either that or its special nature as one of the "almost primitives" in a JVM meant that allowing extension of it had security risks for Java programs in general.

The use of final classes or methods may improve performance, but that would not be the primary reason for their use in general. I've been programming in Java since 1996, version 1.0, and I've never had occasion to use these features. I think of them as things that are useful in esoteric situations that I have not yet had to deal with; I know what they mean and that's enough. Lots of code to be written without worrying about it, certainly not for performance enhancement.

rc

[Campbell Ritchie]

The great advantage of a final class is that it is part of the immutable object pattern. If a supposedly immutable class is not final, it is possible to add additional methods or fields, and change the state of that object. You now lose immutability.

[Stephan van Hulst]

Yes. Either design you class for inheritance very very carefully (think of policies for finalize, clone, hashCode, equals; think about self-use; think about contracts and documentation; etc.) or make classes final.

Most of the time, you don't need your classes to be extensible, so make them final.

[Ralph Cook]

Well, that's one way of looking at it.

Another is "You don't know what use might be made of your classes, so leave them extensible".

Especially since most of us are not writing immutable classes, most of us are writing some form of business object (or "logic object"?), representing some entity in the system. I think it more likely that someone will think of a special case of that class than that you will gain anything by putting 'final' all over the place in your code. I mean, we're OO programmers, aren't we? Why limit what someone does by extending our class?

rc

[Stephan van Hulst]

Because composition is much more robust and secure. If someone wants to reuse your class, they can delegate to it.

Yes, this produces a lot of boiler plate code, but it's preferable to the alternative of leaving a class extensible, when it is not designed to be extensible.

Also, a final class can easily be made non-final in the future. Once you make a class extensible, you may never make it final again.

[Ralph Cook]

I know there are people that believe that, but this emphasis on composition over extension has no basis in fact that I've seen. To delegate to it requires more work, sometimes horrendously more work, and the philosophy as a general rule throws away the useful tool that extension is.

Now, I am NOT NOT NOT saying that extension should always be used; I am saying that, in general, especially for application objects, things are more flexible if extension is left as a possibility. I've not seen any evidence that we should prefer composition. Some situations call for one, some for the other.

And all of you that think you should use composition in preference need to set yourself the task of a moderately complex Swing application. Make sure you do not extend any Swing classes, but instead delegate to them. And rewrite all their methods to pass through to your delegate. And good luck.

rc

[Ralph Cook]

Now, in deference to the forum, I am going to stop watching this thread. I know others will have to have the last word, and they may -- I'm not going to read it any more. We don't need to attempt any kind of a resolution to this in this thread, or even in this forum, so I'm ending my involvement here.

rc

[Stephan van Hulst]

I agree that extension is very powerful and useful. I'm just saying that if you *are* going to make your class extensible, do it properly. Override clone, provide a finalize guard if you need one, document all your methods and their self-use carefully, choose whether to provide equals/hashCode functions *or make them final*, etc.

There's nothing wrong with leaving your classes open for extension "just in case". Just make sure that they are ready to be extended.

Either way, someone has to do a lot of work, either in delegating or making the class safe for inheritance. There is no excuse for lazy programming that compromises robustness.

[Jesper de Jong]

Note that the book Effective Java has a few things to say about this.

If you have the book*, have a look at:

Item 16: Favor composition over inheritance
Item 17: Design and document for inheritance or else prohibit it

Item 17 says that you should either carefully design your class to be extended via inheritance, or if you don't, then make it impossible to extend the class by making it final.

*: If you don't have this book, go and order it right now! Every Java programmer should know the contents of this book.

[gracelyn frida]

Hi,

I think the following notes wil be used for clarifying your doubts

final is a keyword.its constant.it cant be changed from its
initiated value.

finally() method used exception handling concept.finally()
block will execute whether or not try block can be execute.
its used to close a file.

finalize is used when an object is just before deleted,it
can be used in garbage collection.

[Stephan van Hulst]

Welcome to JavaRanch Gracelyn!

Take note that finally is not a method, but a keyword.

[Campbell Ritchie]

And finalize() is rarely useful.