ICloneable - Me Vs My Book

Hello, on my ongoing learning of Interfaces I'm now reading about the ICloneable interface, which its quite easy to understand (the basics anyway!)

well in the book I'm reading the author gave an example of how to clone a class that implements the ICloneable interface. cloning basic class is quite simple, just return the MemberwiseClone and you get (not true) deep copy:

Code:

---

public object Clone()
        {
            return this.MemberwiseClone();
        }

---

well that's only work if you don't have any references to other classes inside the class you're copy, if you do those references will be shallow copy (only the references to memory will get copied)

what the author suggested to do is to first get shallow copy:

Code:

---

Point newPoint = (Point)this.MemberwiseClone();

---

and then start to copy the reference class and fill the gaps:

Code:

---

PointDescription currentDesc = new PointDescription();
currentDesc.PetName = this.desc.PetName;
newPoint.desc = currentDesc;
return newPoint;

---

it looked to me like hard work if the reference class has a lot of properties, what i did instead is to implement the ICloneable interface in the reference class as well, and return its MemberwiseClone too, like so:

Code:

---

public object Clone()
        {
            Point CPoint = (Point)this.MemberwiseClone();
            PointDescription desc = new PointDescription();
            desc = (PointDescription)this.test.Clone();
            CPoint.test = test;
            return CPoint;
        }

---

which work as well with a lot less work.

so my question is basically is, is it bad idea to use the ICloneable interface like i did? is it consider bad practice ?
is using the ICloneable reduce my app performance ?

Thanks!

Copying objects is a bit of a grey area. Creating a shallow copy is easy, thanks to MemberwiseClone. Creating a deep copy is not so easy. Strictly speaking, a deep copy means copying the object referred to by each reference type field. That's not necessarily simple, because those objects may not provide a simple mechanism for doing so. If it's your own class then you can certainly implement ICloneable again on the referenced type, but if it's not your own type then you don't have that luxury.

Generally speaking, if you're going to expose classes publicly, it's polite to provide an ICloneable implementation unless you have a specific reason not to. If you're using types internally only then the choice is yours.

You're correct, I never took into consideration the situation where I don't have control over one of the classes, then I'll have to use the method described in the book I'm reading.

one more simple question though: while I was reading about the ICloneable and IComparable interfaces a thought cross through my mind, I can achieve the same functionality those interfaces provides by using the LINQ technology with much less effort, specially when we talking about the IComparable interface, of course I will keep learn about those interfaces cause i want to improve my knowledge but I doubt that I will ever prefer to implement the IComparable interface while i can do the exact same task writing simple LINQ query.

am I right?

Cloning can be done simply by serializing and deserializing the object... With LINQ you keep the same reference.

Again, only if the class you working with supports serializing.

Quote:

---

Originally Posted by motil

while I was reading about the ICloneable and IComparable interfaces a thought cross through my mind, I can achieve the same functionality those interfaces provides by using the LINQ technology with much less effort, specially when we talking about the IComparable interface, of course I will keep learn about those interfaces cause i want to improve my knowledge but I doubt that I will ever prefer to implement the IComparable interface while i can do the exact same task writing simple LINQ query.

am I right?

---

LINQ is good for ad hoc sorting but if it makes sense for a type to be sorted a particular way all or most of the time then it's most appropriate to implement IComparable. For instance, if you have a Person class with FirstName and LastName properties, it would probably make sense to sort by LastName and then FirstName most, if not all, of the time. As such, by implementing IComparable means that you can simply call Sort on a List or array of Person objects, whereas using LINQ would require you to specify the two criteria for comparison every time. Especially if you're making the type available to others, the proper thing to do is to implement IComparable if it is logical to do so.

Besides, in order to use LINQ to sort objects, you're still relying on the IComparable interface anyway. The LINQ OrderBy method and the like rely on IComparable in order to compare objects to decide order.

What I did so far was to create static methods inside the classes the use LINQ something like so

Code:

---

public class Person
{
....

#Region Sort & Filter methods
public static List<Person> SortByFirstName(List<Person> lst) {
  return lst.OrderBy(x => x.FirstName);
}
#Region
}

---

It makes absolutely no sense to do what you've done there. What do you gain by doing that over implementing IComparable? Nothing. What do you lose? The ability to compare two instances directly. The ability to sort an array. The ability to sort an existing List (your method does not sort the existing List but rather returns a new one). That is a very, VERY bad idea.

well, I'm still learning.
this is why i opened this thread and this is why you helping people :)

I'll implement this IComparable interface for ordering purpose from now on.

Thanks again.