DEV Community

loading...

Discussion on: Why does Object class have "protected" clone() method?

Collapse
nfrankel profile image
Nicolas Frankel

That's a great question!

Even language designers make mistakes sometimes. Here's what I wrote about it a couple of years ago.

Collapse
abh1navv profile image
Abhinav Pandey Author

I was more concerned about it being protected but I found the thinking behind it here.

Thanks for the blog. That seems ok. It is indeed debatable why marker Interfaces do not expose the methods that should be related to them.

However, I see a counterpoint to your blog.

If clone() was not implemented in Object, we would have to implement it in our cloneable concrete classes and there will be no super.clone() to rely on.

Keeping that in mind, the design does not look that bad for the initial introduction of the method.

  1. It gave us a way to choose if objects should be cloneable or not. No singleton logic would work if all objects were cloneable by default.
  2. It gave us a default implementation too so that we won't have to handle it ourselves. I'm not an expert but it must be tough to implement something on our own which was implemented by native code.

But what you suggest in your blog is definitely a better design. Specially now that it is possible to define "default" methods in interfaces, it could be better design to adapt it in newer versions.

What I'm sure about is that it was anyways good that it was implemented already for us and Object class was the only possible place to implement it at that point of time.

Forem Open with the Forem app