Why is clone() method protected?
posted 21 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
If the "protected" access atribute means access only through subclasses and if Object class is on the top of the hierarchy with all the other classes being its subclasses, why is clone() method protected then? Maybe because sometimes we would need to override it with a clone() that has more-restrictive-than-public atribute? If so, when does such a need arise? 

posted 21 years ago
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
Almost, I think.
Suppose it was coderanch. That means that you can call clone() from any other class. Now - you don't want to do this, because you want to control the call for clone() on your objects.
Also, you can always declare your class final - and that's where you end the inheritance. So - if you can't extend class X - you can't get its clone() method as well.
Nimo.
Suppose it was coderanch. That means that you can call clone() from any other class. Now - you don't want to do this, because you want to control the call for clone() on your objects.
Also, you can always declare your class final - and that's where you end the inheritance. So - if you can't extend class X - you can't get its clone() method as well.
Nimo.
posted 21 years ago
-
1 -
-
Number of slices to send:Optional 'thank-you' note:
-
-
clone() is a mystery wrapped in a riddle:
(1) clone() will not function unless class also implements Cloneable
(2) Object itself doesn't implement Cloneable, so you can't invoke clone() directly .. only on a Cloneable sub-class
(3) Even as a sub-class of Object, you can't clone() unless you implement the Cloneable interface, yet the Cloneable interface (like Serializable) has no methods!
Viewed this way, the 'protected' modifier makes sense:-) The bigger picture adds up to a restrictive invocation environment for clone()
since neither cloning nor serialization are not guaranteed to succeed (especially on 'mutable' objects), it is probably healthy to be forced to do an explicit implementation, and deal with exceptions then and there
there's also a security perspective - if you could clone() *all* Object subclasses by default ... security would be, well, pretty messy.
As it is, you have much more control. You can
1. implement Cloneable, and let Object manage the clone() , and just handle exceptions,
2. implement Cloneable, and explicitly manage (what gets cloned and how) in your clone() method
3. passively prohibit cloning of your objects by *not* implementing Cloneable, or
4. actively prohibit cloning by implementing Cloneable and throwing a CloneNotSupportedException in the clone() method
hth
(1) clone() will not function unless class also implements Cloneable
(2) Object itself doesn't implement Cloneable, so you can't invoke clone() directly .. only on a Cloneable sub-class
(3) Even as a sub-class of Object, you can't clone() unless you implement the Cloneable interface, yet the Cloneable interface (like Serializable) has no methods!
Viewed this way, the 'protected' modifier makes sense:-) The bigger picture adds up to a restrictive invocation environment for clone()
since neither cloning nor serialization are not guaranteed to succeed (especially on 'mutable' objects), it is probably healthy to be forced to do an explicit implementation, and deal with exceptions then and there
there's also a security perspective - if you could clone() *all* Object subclasses by default ... security would be, well, pretty messy.
As it is, you have much more control. You can
1. implement Cloneable, and let Object manage the clone() , and just handle exceptions,
2. implement Cloneable, and explicitly manage (what gets cloned and how) in your clone() method
3. passively prohibit cloning of your objects by *not* implementing Cloneable, or
4. actively prohibit cloning by implementing Cloneable and throwing a CloneNotSupportedException in the clone() method
hth
| Get meta with me! What pursues us is our own obsessions! But not this tiny ad: The new gardening playing cards kickstarter is now live! https://www.kickstarter.com/projects/paulwheaton/garden-cards |









