• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

final method inside final class

 
Ranch Hand
Posts: 216
Tomcat Server Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the sense behind making a final method in the final declared class ??

I mean if you can't subclass a final class then by making a final method inside it doesn't make any sense .

Is it correct ? or i missed anything.
 
Ranch Hand
Posts: 333
Firefox Browser Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why we do explicit abstract declaration of an interface ?
 
Nikhil Sagar
Ranch Hand
Posts: 216
Tomcat Server Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

ankita modi. wrote:Why we do explicit abstract declaration of an interface ?



i never do.
I think you are trying to say that it is allowed but there is no sense to declare them abstract because they are implicitly abstract.
But i am unable to locate any documentation in the JLS who says that methods in the final class are implicitly final.
So, if it is it then it and compiler complains whenever it sees a expression who has a final class name after extends keyword thats why there is no sense to put final keyword in method signature of a final class because if you can't subclass a final class then how can you override any of its method so no need to prevent any method of a final class to be overridden then i think compiler is much intelligent and can think "Why not i skip to put final keyword in each method's signature of a final class because there is no trick to override it.Lets do something else and save some time."
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nikhil Sagar wrote:Is it correct ? or i missed anything.


Not literally; but there is
(a) the fact that your design may change.
(b) what you regard as "good habits".

Personally, I always make BOTH (class and method defintiions) final by default; because you can always undo that decision. What you can't do is add the final keyword anywhere after a class is published.

Putting it on both means that if you remove final from the class, you don't affect any of its methods.

Winston

PS: Two great cases in point are BigDecimal and BigInteger: Josh Bloch (who wrote them) freely admits that they should have been made final; but, once published, there was no way it could be added without compromising existing code. Therefore, in theory, you should check all BigInteger's received from an untrusted source to make sure that they're not some naughty subclass.
 
Nikhil Sagar
Ranch Hand
Posts: 216
Tomcat Server Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

PS: Two great cases in point are BigDecimal and BigInteger: Josh Bloch (who wrote them) freely admits that they should have been made final; but, once published, there was no way it could be added without compromising existing code. Therefore, in theory, you should check all BigInteger's received from an untrusted source to make sure that they're not some naughty subclass.



I was just replying about this but then got an mail that you updated your post.
So, as i can see that...

Personally, I always make BOTH (class and method defintiions) final by default; because you can always undo that decision. What you can't do is add the final keyword anywhere after a class is published.



This is a good idea but if you are in your testing or developing phase.
Once deployed then making a final class to non-final is a VERY VERY BIG decision rather i can imagine a shouting project manager pointing towards me.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nikhil Sagar wrote:This is a good idea but if you are in your testing or developing phase.


I'm not quite sure why that should make a difference. Either a class already has a subclass or it doesn't. If it doesn't, leave it (and all its methods) final.
I suppose it's possible that testing might show you that a subclass isn't needed; in which case, make the superclass and all its methods final as soon as you realise this.

About the only exception to this would be if you're writing a framework, where you want all your classes to be as extensible as possible; however, I'd probably then base everything around interfaces and skeleton (ie, abstract) implementations; and I'd still make all non-abstract methods final until I found a reason that they shouldn't be.

Winston
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:Either a class already has a subclass or it doesn't. If it doesn't, leave it (and all its methods) final.


Going back to Josh Bloch, EJv2 has an entire Item (#17) devoted to the subject, and it's called "Design and document for inheritance, or else prevent it". My only wrinkle is that I prevent it at both levels (class and method) by default.

Some may regard it as excessive, but I reckon that a bit of paranoia is quite healthy in a programmer.

Winston
 
Nikhil Sagar
Ranch Hand
Posts: 216
Tomcat Server Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:

Nikhil Sagar wrote:This is a good idea but if you are in your testing or developing phase.


I'm not quite sure why that should make a difference.



And i always thought that making a class final means that developer is quite sure that his class is perfectly complete class and there is no need to subclass it.
I am still not sure that after deployment making such a decision is good or not because i think many existing users of this class can complain about it that Why now ?? Why did you make it final at deployment time if you were not sure, that could make my code less complex.
Well, Thanks for the link Winson i would like to read that book.
And thanks for the Disscussion too.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nikhil Sagar wrote:And i always thought that making a class final means that developer is quite sure that his class is perfectly complete class and there is no need to subclass it.
I am still not sure that after deployment making such a decision is good or not because i think many existing users of this class can complain about it that Why now ?? Why did you make it final at deployment time if you were not sure, that could make my code less complex.


You certainly have a point; I'm just not sure it's good enough to warrant compromising good practise for.
1. Hopefully, there's some mechanism in place to provide feedback from your users; and if people find your class difficult to use specifically because it's final, you can always change your mind later on. What you can't do, as I said above, is make a non-final class final after the fact.
2. There are other ways of extending classes than just inheritance - the main one being composition - and they're often preferable to strict hierarchies.

And on the subject of point 2, I can think of one example of a class that shouldn't be final, and neither should it's methods: a reusable "forwarder" or "wrapper" class. For example, I have a CharsWrapper class that I use for wrapping CharSequence's (which include Strings), and it looks like:Now it doesn't look like much on its own; but I've used it as a base for creating a couple of useful (and final ) subclasses, including a "fast search" class that uses the Horspool algorithm.

Winston
 
Nikhil Sagar
Ranch Hand
Posts: 216
Tomcat Server Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:

Nikhil Sagar wrote:And i always thought that making a class final means that developer is quite sure that his class is perfectly complete class and there is no need to subclass it.
I am still not sure that after deployment making such a decision is good or not because i think many existing users of this class can complain about it that Why now ?? Why did you make it final at deployment time if you were not sure, that could make my code less complex.


You certainly have a point; I'm just not sure it's good enough to warrant compromising good practise for.
1. Hopefully, there's some mechanism in place to provide feedback from your users; and if people find your class difficult to use specifically because it's final, you can always change your mind later on. What you can't do, as I said above, is make a non-final class final after the fact.
2. There are other ways of extending classes than just inheritance - the main one being composition - and they're often preferable to strict hierarchies.

And on the subject of point 2, I can think of one example of a class that shouldn't be final, and neither should it's methods: a reusable "forwarder" or "wrapper" class. For example, I have a CharsWrapper class that I use for wrapping CharSequence's (which include Strings), and it looks like:Now it doesn't look like much on its own; but I've used it as a base for creating a couple of useful (and final ) subclasses, including a "fast search" class that uses the Horspool algorithm.

Winston



Thank Winson for the very valuable Information.
I am already a fan of your.
 
Nikhil Sagar
Ranch Hand
Posts: 216
Tomcat Server Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Winson, please tell me just one last time that is it a good practice you are talking about because you know you can't argue much with Project managers ?
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nikhil Sagar wrote:Winson, please tell me just one last time that is it a good practice you are talking about because you know you can't argue much with Project managers ?


Depends what they're asking (or telling you) to do.

My approach could be accurately described as 'paranoid': I don't trust anybody to use anything I write the way they're supposed to; and that starts with the design. I used to be a security administrator, and one of the first things I was taught is that there are two basic paradigms for security:
1. That which is not specifically denied is allowed.
2. That which is not specifically allowed is denied.

The first causes a lot less fuss, but is a LOT more difficult to implement. The second will make you a lot of enemies, but allows you to guarantee (in as much as you can guarantee anything) that your system is safe.

My approach to the final keyword can be likened to number 2: I don't let anyone extend my classes or override my methods unless I decide so. It's simple, and I'm God - and that's the way I like it.

In 35 years of programming, I haven't had it steer me wrong yet; but whether it's "good practise" or not might depend on what you're doing.

My suggestion: If your manager is a techie (or ex-techie), bang off a printout of this discussion and show it to him/her and see what they say. At the very least they'll then know that your misgivings aren't simply "gut" feeling, and based on something rational.

Winston
 
Nikhil Sagar
Ranch Hand
Posts: 216
Tomcat Server Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My suggestion: If your manager is a techie (or ex-techie), bang off a printout of this discussion and show it to him/her and see what they say. At the very least they'll then know that your misgivings aren't simply "gut" feeling, and based on something rational.



It will be On My Office's Bulletin Board for sure.


Except...


My approach to the final keyword can be likened to number 2: I don't let anyone extend my classes or override my methods unless I decide so. It's simple, and I'm God - and that's the way I like it.




Lets see the reaction of others...
cheers..
 
reply
    Bookmark Topic Watch Topic
  • New Topic