David Jencks wrote:
On Oct 27, 2007, at 11:56 AM, Alex Karasulu wrote:
Hi Emmanuel, and others,
I was taking another look at these ServerEntry interfaces etc and
noticed that you define
the clone() method as supported within the interfaces themselves.
I may be wrong but I've always tried to avoid defining the clone()
method in interfaces and
have gone to great lengths to avoid using the clone() method. I
prefer to use factories or
constructors instead. For me the clone operation is scary and leads
to a lot of confusion.
Most of the time unless I have to support it because of a class I'm
extending I will deal with
it but when I can I try to avoid it.
Emmanuel was wondering if you see supporting clone() as critical and
recommend we keep
it?
I know just having a feeling is not enough to say using clone is
dangerous but I've always ran
into issues with it and the variance in the semantics to the point
where dealing with it was not
worth the trouble.
Please could anyone with a clearer understanding of the pros and cons
provide some further
guidance on this topic?
I doubt I have a clearer understanding but Joshua Bloch's Effective
Java has 8 pages pointing out how hard it is to write clone methods
correctly and the problems they cause and how copy constructors or
factory methods have much clearer semantics and implementations. I
never feel like I know what is going to happen when I call clone :-)
Beside being the worst episode of Star Wars, I wouls say that clone is
not my favorite Java feature, but I used it a couple of times without
problems. The rules I have adopted were pretty simple : if it start to
be complex, stop using clone... In fact, when it's strait forward, like
you have a flat object, or a very simple inheritance scheme, clone() is
an option. Otherwise, a good factory or copy() constructor is the way to
go.
When performance is an issue, then clone may become a candidate, but
with a lot of caution...
E.clone() (or is it E.clown() ? ;)
