Type-safe copy interface

Hi,

I am trying to implement an interface in C# that requires implementing classes to return a copy of themselves in a type-safe manner (i.e. returning the implementing class' own type, NOT an IExample type). I google'd around a bit, but did not find a satisfactory design pattern. The solution I hacked together was (abstracting everything possible away):

Code:

---

public interface IExampleCore
{
    bool exampleCommonMethod();
    bool anotherExample();
    IExampleCore deepCopyCore();
}

public interface IExample<T> : IExampleCore where T : IExample<T>
{
    T deepCopy();
}

---

And finally implementing an object like:

Code:

---

public class ExampleClass : IExample<ExampleClass>
{
    public bool exampleCommonMethod() { ... }
    public bool anotherExample() { ... }
    public ExampleClass deepCopy() { ... }
    public IExampleCore deepCopyCore() { return this.deepCopy(); }
}

---

This seems to compile OK, but it seems like a long way to go to implement a type safe deep copy. I am particularly concerned about the where directive wherein T is used in the constraint. This seems circular, however logical it seems in my mind. Is this appropriate? Is there a better way?

Note I do also want to support a non-type safe call to anything implemeting IExampleCore (or IExample<T>, by extension) that returns merely an IExampleCore (hence the deepCopyCore() method) in addition to the type-safe deepCopy().

Any advice would be much appreciated. Thanks.

I hate to bump this, but was still curious if there was a design pattern I was missing: sorry! I asked this question back in February to not much response. Does anyone happen to have any information on this? I'd be interested to know if there was a better design pattern than the (clunky) one above. Any advice would be much appreciated.

I cannot right now, but the subject is interesting. While you're here, take a look at your PM.
What's wrong with the IExample return type ?you return an implemented class, but those who call you will dialogue with you via the interface even if they receive an implemented class...

***edit. Got it. You are on high levels...


by the way, I have looked at design patterns for deep copy. An interesting stuff is here
http://msdn.microsoft.com/en-us/libr...730-01-05.aspx
where, among other stuff I read:

Quote:

---

Part of the Prototype pattern then relies on a namespace with two methods: Clone and DeepCopy. In fact, Clone is merely a synonym for MemberwiseClone and can be omitted. The namespace is shown in Example 5.1, "Prototype pattern theory code-namespace".

---

we also have had a post on that herearound
http://www.codeguru.com/forum/showthread.php?t=242411

and the guys here made some interesting observations:
http://stackoverflow.com/questions/1...c-specifically

none however seems to have focused on the "passing Interface" matter.

If you're asking what kind of interface you can create in order to force the implementing class to create a deep copy of the object (as opposed to being able to break the semantics defined by the interface, and return a shallow copy instead) - I'm not sure it can be done.

This is one of those things where you rely on whoever is writing the implementation to follow the rules. For example, your solution entirely depends on the implementation of the deepCopy() method.

On the other hand, if your question isn't as much concerned with implementing deep copy behavior, as it is with providing an abstract interface that can ensure that the right type of object is returned (the contextual implementing type, as opposed to some other implementing type), then - I think it's only partly possible.
There are other potential problems that you might not be able to prevent: what if the method returns a subtype of this type, or if it returns an different object of the same type, or even null?
An "innovative" developer could even return a entirely different type which implements IExample<ExampleClass> (no error there - ExampleClass satisfies the constraint).
Again, it all completely depends on the implementation of deepCopy().

I think this is one of those things where your responsibility as the API designer stops when you define what the method means and how it fits in your library/framework, and since apparently there are no mechanisms to enforce that the semantics are followed, the responsibility falls on the one implementing your interface.

But, that's the case with almost any method: for example, an interface that defines the following method:

int Add(int a, int b);

provides you with no way to enforce that, when implemented, the method actually adds the numbers a and b. If you wanted to do something... well, let's call it funny, you could hack-up an implementation that, say, subtracts them, then starts a BackgroundWorker task, plays some sounds and animation, starts Notepad.exe, downloads a web page, and then returns an integer result. The compiler wouldn't mind...