ICloneable ... why type it out?

  • Thread starter Thread starter smith
  • Start date Start date
S

smith

I've been making deep copy clones of objects since my second week or so with
..Net (it took me the first week to realize that shallow copies were usually
worthless as "clones").
Normally I call my method "Clone" ... it's just a naming habit I got into
with VB5/6 using LSET on UDTs for serializing state and creating copies of
objects.

The way I do it is of course with .Net is the wya most everyone does it,
mark the class with the Serializable attribute, implement ISserializable
with it's constructor and GetObjectData. The Clone method does the
traditional binaryformater and memory stream serialization and the method
returning an object of the same type as the running instance (though I often
overload the Clone method and use custom serialization to instead convert
the object to another type, such as a state-only object for tighter
remoting). No rule breaking here, ISerializable's "propertybagish" system
is logical.

But, here's the question: In my three years of primarily doing .Net, most of
my clones (found in nearly every one of my apps) never specifically
implemented ICloneable. I'll add it if I'm feelign picky but even when I do
add it, I always just look at that interface and scratch my head ... There
seems to be nothing worthwhile in using it, since I'm doing all of the
actual work myself, using the syntax (albeit out of pre-.Net habit) and
just don't need the "reminder" that I have a Clone method. Also, my Clones
output an actual type rather than an Object.

Forgive my ignorance, but can you tell me a real reason for specifically
typing out the "Implements ICloneable", beyond just "it's what you're
supposed to do"?

There's doing "the right thing" for a good reason and then there's going
overboard ... in this little thing I wonder the basic logic.

Thanks.

Robert Smith
Kirkland, WA
www.smithvoice.com
 
Consistency perhaps? I'd say that people consuming your libraries (if that
were the case) would expect to use a standard CLR interface to achieve
cloning. Not that you couldn't do it the way you describe, but still.

It's kinda like always inheriting from EventArgs when creating complex types
to pass to delegate handlers. You don't have to, but it's nice to "stick" to
the "standard", I guess.
 
Thanks Klaus (and good to talk to you again). I do understand the tradition
of it and I grasp the idea (while Inheriting and implementing an interface
are a little bit different) but this particual interface just strikes me as
less than real-world logical for some reason.

Perhaps the aspect that bothers me about it most is that the return type of
the interface's Clone method is "Object" when it seems to me a Clone should
return an object of the exact type of the source and casting shouldn't be
needed; Granted the only way to generalize is to make the return an "Object"
but since in this case there's only just the one method in the interface ...
oy, Even right now as I try to just accept it as "what you should do because
that's how it's done" it just continues to look like a silly interface.

It's not that it's a major deal, my code hasn't failed over it and others do
tap into my dlls. I just see newer devs just catching the .Net religion and
following little things like this as if they're some rule from God and
wonder if there's some tangible performance issue I've been missing out on.

Thanks.

-smith
www.smithvoice\.com
 
It's not that it's a major deal, my code hasn't failed over it and others
do tap into my dlls. I just see newer devs just catching the .Net
religion and following little things like this as if they're some rule
from God and wonder if there's some tangible performance issue I've been
missing out on.
Click to expand...

No performance issues, just potential consistency and compatibility issues.
Most interfaces exist for the benefit of API's and\or languages(usually
api's). It is far easier, faster, and safer to determine Clone generically
via an ICloneable interface than it is, say, via reflection.
If you had a generic object manager(not specialized to a specific tree) that
clones objects to maintain a pool or a language that provides a "copy" or
"clone" keyword, both of those would likely rely on ICloneable in a generic
sense, or would have anyway.

The issue with ICloneable is that it doesn't specify deep or shallow copy.
Its use is...less valuable that the designers probably intended. I would
pretty strongly suggest foregoing ICloneable and using your own cloning
method\interface to specify clone functionality. Just remember to specify if
the method is deep, shallow, or object-specific. Being unsure of
expectations is a considerable problem.

I would certainly, however, recommend an interface or common base class
instead of just adding Clone methods everywhere. This may not be feasible
until the 2.0 release, however.
 
Back
Top