Bear Bibeault wrote:Here's a question for you to answer: why should it not be final?
Campbell Ritchie wrote:Welcome to the Ranch
If you subclass a class, you do that so you can create instances of both the class and of the subclass. (And that works even if the superclass is abstract.) The System class is uninstantiable, so you cannot create subclass instances. You can therefore not extend from System.
You will find the same applies to most utility classes.
Still a beginner at crafting quality coding but have the zeal to learn more. Your help would be appreciated.
My Blog on Learning Analytics
OCPJP
Steve
Sunit Kumar wrote:In my perspective, if we remove final it does make any difference because its private constructor would not allow to any other class to extend it.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Sunit Kumar wrote:
Bear Bibeault wrote:Here's a question for you to answer: why should it not be final?
In my perspective, if we remove final it does make any difference because its private constructor would not allow to any other class to extend it.
Sunit Kumar wrote:
Campbell Ritchie wrote:Welcome to the Ranch
If you subclass a class, you do that so you can create instances of both the class and of the subclass. (And that works even if the superclass is abstract.) The System class is uninstantiable, so you cannot create subclass instances. You can therefore not extend from System.
You will find the same applies to most utility classes.
But private constructor is taking care all of that so why Java API developer put extra keyword "final".
Ashish Dutt wrote:A point to note here, Constructors are not inherited.
Steve Luke wrote:I think Jeff's point is the most applicable. A private constructor means an instance of the class can't be created outside the class declaration. The final keyword means that the class can't be subclassed. If you don't want the class subclassed then make the class final.
The private constructor does NOT replace the final keyword. Take this code:
In this case I want to control the creation of the System instances ... I have a singleton but maybe you have an instance counter or some DB work to get done, or whatever. But you either need to control the instances, provide data others don't have access to or (like in java.lang.System) simply don't have a reason for an instance.
But then a second coder comes, months or years later, and works on the System class. He does this:
System is a non-final class which has a private constructor, but lo: a static inner class can subclass it. Make System final and that is impossible. The second programmer inherited the code, and because the class isn't final he gets no indication that the class should be protected from subclassing. So without further ado, he creates an inner class to get around the private constructor. What is worse is that this would work as well:
Now I have a means of creating new Systems (by System = new System.InSystem() instances) willy-nilly, by-passing the instance controls. Any reason I had for making the private constructor is lost, as would be the design intent of protecting the class from being subclassed. All I have to do to protect from that is make System final. Then none of the problems that the well-intentioned but uninformed second programmer inserted would work. And more importantly the second programmer knows the intent was to keep System from being subclassed, not just to keep instances of it from being created.
Sunit Kumar wrote:So impressive explanation !!! Thank you so much.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Wait for it ... wait .... wait .... NOW! Pafiffle! A perfect tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|