c＃接口方法<T>但实现为concreate

Question

I've created an Interface like so:

public interface ICacheable {
    void CloneTo<T>(T entity) where T : class, new();
}

However, when I implement the interface in a class, I have to define the CloneTo method also using T as the type as follows:

public class MyEntity : ICacheable {
    public void CloneTo<T>(T genericEntity) where T : class, new() {}
}

This does compile and run. However, it's not ideal as I could pass any other item that implements ICacheable to the method where I only want to be able to send an instance of the class. What I really want is to implement it more like this:

public class MyEntity : ICacheable {
    public void CloneTo(MyEntity entity) {}
}

That way I could only pass the proper type of entity.

I tried instead creating the interface as of T, ie

public interface ICacheable<T>

Which did then allow me to tailor the implementing class's method to only accept that type. However, I then could no longer have a List<ICacheable> .

Does anyone know if it's possible to achieve what I'm trying to do here? Thanks!

Answer 1

If you don't want to have List<ICacheable<MyEntity>> you can always have List<object> .

Only other organization I can think off is something like:

public interface ICacheable
{
    void CloneTo(ICacheable entity);
}

public interface ICacheable<T> : ICacheable where T : ICacheable
{
    void CloneTo(T entity);
}

public abstract class Cacheable<T> : ICacheable<T> where T : ICacheable
{
    void ICacheable.CloneTo(ICacheable entity)
    {
        // here it can fail at runtime though
        CloneTo((T)entity);
    }

    public abstract void CloneTo(T entity);
}

public class MyEntity : Cacheable<MyEntity>
{
    public override void CloneTo(MyEntity entity)
    {
        //...
    }
}

So you can have:

var list = new List<ICacheable>();
list.Add(new MyEntity());
var something = new MyEntity();
// works 
list[0].CloneTo(something);

However you can run into issues with code like:

public class SecondEntity : Cacheable<SecondEntity> { ... }
var list = new List<ICacheable>();
list.Add(new MyEntity());
var something = new SecondEntity();
// oops - runtime error
list[0].CloneTo(something);    

Answer 2

You can split your interface to two parts, one containing type-dependant members, another containing type-agnostic members:

public interface ICacheable<T> : ICacheable
    where T : class, new()
{
    // All type-dependant members go here
    void CloneTo(T entity);
}

public interface ICacheable
{
    // All type-agnostic members go here
}

Of course, you won't be able to use CloneTo with the non-generic ICacheable type.

Answer 3

What I really want is to implement it more like this:

public class MyEntity : ICacheable {
  public void CloneTo(MyEntity entity) {}
}

Does anyone know if it's possible to achieve what I'm trying to do here?

The restriction you wish to express cannot be expressed in the C# type system. You'd need a "higher" type system; this restriction could be expressed in Haskell for instance. (Though I would not care to say how; I am no expert on Haskell!)

This does not stop people from trying; I describe the most common "broken" way I see to implement this restriction here:

https://blogs.msdn.microsoft.com/ericlippert/2011/02/03/curiouser-and-curiouser/

I do not recommend that you attempt this curious pattern. Rather than tying the C# type system in knots to try to express a particular restriction, ask yourself what the polymorphism inherent in defining an interface really buys you and your users. Go back to the key user scenarios and see if there is another way to describe your scenario.

For example, here you're trying to represent "a cachable entity may be cloned to another entity". Great. That's the scenario. There is no requirement that you implement that with an ICacheable interface that has a CloneTo method. You could for example say that entities have a "clone from" method. See if that is easier to express in the type system. Or you could say that there is a bigger abstraction here: that some entities may contain clones of others, and whether or not any particular pair of entities have that relationship can be determined by a policy engine; now you must design and implement that engine. And so on. Not every business problem needs to be solved by embedding its rules in the type system.