为什么接口不起作用，但抽象类可以使用泛型类约束? [英] Why doesn't an interface work but an abstract class does with a generic class constraint?

问题描述

下面的代码显示了一个带有类型约束的泛型类 (Pub).该类有一个事件，它可以引发允许我们将消息传递给订阅者.约束是消息必须实现IMsg(或者当它是一个抽象类时从IMsg继承).

The code below shows a generic class with a type constraint (Pub<T>). The class has an event that it can raise allowing us to pass a message to subscribers. The constraint is that the message must implement IMsg (or inherit from IMsg when it's is an abstract class).

Pub 还提供了一个 Subscribe 方法，允许对象订阅 notify 事件，当且仅当对象实现 <代码>IHandler.

Pub<T> also provides a Subscribe method to allow objects to subscribe to the notify event if and only if the object implements IHandler<IMsg>.

使用 .NET 4，下面的代码显示了 baseImplementer.NotifyEventHandler 上的错误，说明:
'IHandler<IMsg>.NotifyEventHandler(IMsg)'没有重载匹配委托'System.Action<T>'"

Using .NET 4, the code below shows an error on baseImplementer.NotifyEventHandler stating that:
"No overload for 'IHandler<IMsg>.NotifyEventHandler(IMsg)' matches delegate 'System.Action<T>'"

public interface IMsg { }        // Doesn't work
//public abstract class IMsg { } // Does work

public class Msg : IMsg { }

public class Pub<T> where T : IMsg
{
    public event Action<T> notify;

    public void Subscribe(object subscriber)
    {
        // Subscriber subscribes if it implements IHandler of the exact same type as T
        // This always compiles and works
        IHandler<T> implementer = subscriber as IHandler<T>;
        if (implementer != null)
            this.notify += implementer.NotifyEventHandler;
        // If subscriber implements IHandler<IMsg> subscribe to notify (even if T is Msg because Msg implements IMsg)
        // This does not compile if IMsg is an interface, only if IMsg is an abstract class
        IHandler<IMsg> baseImplementer = subscriber as IHandler<IMsg>;
        if (baseImplementer != null)
            this.notify += baseImplementer.NotifyEventHandler;
    }
}

public interface IHandler<T> where T : IMsg
{
    void NotifyEventHandler(T data);
}

下面的代码不是重现问题所必需的......但显示了如何使用上面的代码.显然IMsg(以及派生的Msg)类将定义或实现可以在处理程序中调用的方法.

Code below here is not necessary to reproduce the issue... but shows how the code above might be used. Obviously IMsg (and the derived Msg) classes would define or implement methods that could be called in a handler.

public class SubA : IHandler<Msg>
{
    void IHandler<Msg>.NotifyEventHandler(Msg data) { }
}

public class SubB : IHandler<IMsg>
{
    void IHandler<IMsg>.NotifyEventHandler(IMsg data) { }
}

class MyClass
{
    Pub<Msg> pub = new Pub<Msg>();
    SubA subA = new SubA();
    SubB subB = new SubB();

    public MyClass()
    {
        //Instead of calling...
        this.pub.notify += (this.subA as IHandler<Msg>).NotifyEventHandler;
        this.pub.notify += (this.subB as IHandler<IMsg>).NotifyEventHandler;

        //I want to call...
        this.pub.Subscribe(this.subA);
        this.pub.Subscribe(this.subB);

        //...except that the Subscribe method wont build when IMsg is an interface
    }
}

推荐答案

为什么将 IMsg 更改为抽象类而不是接口后错误就会消失?

Why does the error go away as soon as I change IMsg to an abstract class instead of an interface?

好问题！

失败的原因是因为您在从方法组到委托类型的转换中依赖于形式参数逆变，但是协变和逆变方法组转换到委托仅在已知每个变化类型都是引用类型时才是合法的.

The reason this fails is because you are relying upon formal parameter contravariance in the conversion from the method group to the delegate type, but covariant and contravariant method group conversions to delegates are only legal when every varying type is known to be a reference type.

为什么可变类型不是已知为引用类型"?因为T 上的接口约束不会同时将 T 约束为引用类型.它将 T 约束为实现接口的任何类型，但结构类型也可以实现接口！

Why is the varying type not "known to be a reference type"? Because an interface constraint on T does not also constrain T to be a reference type. It constrains T to be any type that implements the interface, but struct types can implement interfaces too!

当你使约束成为抽象类而不是接口时，编译器知道 T 必须是引用类型，因为只有引用类型才能扩展用户提供的抽象类.编译器然后知道差异是安全的并允许它.

When you make the constraint an abstract class instead of an interface then the compiler knows that T has to be a reference type, because only reference types can extend user-supplied abstract classes. The compiler then knows that the variance is safe and allows it.

让我们看看你的程序的一个更简单的版本，看看如果你允许你想要的转换它会出错:

Let's look at a much simpler version of your program and see how it goes wrong if you allow the conversion you want:

interface IMsg {}
interface IHandler<T> where T : IMsg
{
    public void Notify(T t);
}
class Pub<T> where T : IMsg
{
    public static Action<T> MakeSomeAction(IHandler<IMsg> handler)
    {
        return handler.Notify; // Why is this illegal?
    }
}

那是非法的，因为你可以说:

That's illegal because you could then say:

struct SMsg : IMsg { public int a, b, c, x, y, z; }
class Handler : IHandler<IMsg> 
{
    public void Notify(IMsg msg)
    {
    }
}
...
Action<SMsg> action = Pub<SMsg>.MakeSomeAction(new Handler());
action(default(SMsg));

好的，现在想想它的作用.在调用方，该操作期望在调用堆栈上放置一个 24 字节的 struct S，并期望被调用方处理它.被调用者 Handler.Notify 期望在堆栈上有一个 4 或 8 字节的堆内存引用.我们刚刚将堆栈错位了 16 到 20 个字节，结构的第一个或两个字段将被解释为指向内存的指针，从而导致运行时崩溃.

OK, now think about what that does. On the caller side, the action is expecting to put a 24 byte struct S on the call stack, and is expecting the callee to process it. The callee, Handler.Notify, is expecting a four or eight byte reference to heap memory to be on the stack. We've just misaligned the stack by between 16 and 20 bytes, and the first field or two of the struct is going to be interpreted as a pointer to memory, crashing the runtime.

这就是为什么这是非法的.在处理动作之前需要对结构体进行装箱，但您没有提供任何用于装箱结构体的代码！

That's why this is illegal. The struct needs to be boxed before the action is processed, but nowhere did you supply any code that boxes the struct!

有三种方法可以使这项工作发挥作用.

There are three ways to make this work.

首先，如果您保证所有内容都是引用类型，那么一切都会解决.您可以使 IMsg 成为类类型，从而保证任何派生类型都是引用类型，也可以将类"约束放在程序中的各种T"上.

First, if you guarantee that everything is a reference type then it all works out. You can either make IMsg a class type, thereby guaranteeing that any derived type is a reference type, or you can put the "class" constraint on the various "T"s in your program.

其次，您可以始终如一地使用 T:

Second, you can use T consistently:

class Pub<T> where T : IMsg
{
    public static Action<T> MakeSomeAction(IHandler<T> handler) // T, not IMsg
    {
        return handler.Notify; 
    }
}

现在你不能将 Handler 传递给 C.MakeSomeAction -- 你只能传递一个 Handler>，这样它的 Notify 方法就需要传递的结构体.

Now you cannot pass a Handler<IMsg> to C<SMsg>.MakeSomeAction -- you can only pass a Handler<SMsg>, such that its Notify method expects the struct that will be passed.

第三，您可以编写执行装箱的代码:

Third, you can write code that does boxing:

class Pub<T> where T : IMsg
{
    public static Action<T> MakeSomeAction(IHandler<IMsg> handler) 
    {
        return t => handler.Notify(t); 
    }
}

现在编译器看到，啊，他不想直接使用handler.Notify.相反，如果需要进行装箱转换，则中间函数会处理它.

Now the compiler sees, ah, he doesn't want to use handler.Notify directly. Rather, if a boxing conversion needs to happen then the intermediate function will take care of it.

有意义吗?

从 C# 2.0 开始，方法组到委托的转换在参数类型上是逆变的，在返回类型上是协变的.在 C# 4.0 中，我们还在接口和委托类型的转换上添加了协变和逆变，这些类型被标记为对变化是安全的.从您在这里所做的各种事情看来，您可能会在接口声明中使用这些注释.有关必要背景，请参阅我关于此功能的设计因素的长系列.(从底部开始.)

Method group conversions to delegates have been contravariant in their parameter types and covariant in their return types since C# 2.0. In C# 4.0 we also added covariance and contravariance on conversions on interfaces and delegate types that are marked as being safe for variance. It seems like from the sorts of things you are doing here that you could possibly be using these annotations in your interface declarations. See my long series on the design factors of this feature for the necessary background. (Start at the bottom.)

http://blogs.msdn.com/b/ericlippert/archive/tags/covariance+and+contravariance/

顺便说一句，如果您尝试在 Visual Basic 中使用这些类型的转换诡计，它会很高兴地允许您这样做.VB 会做最后一件事；它会检测到类型不匹配，而不是告诉您它以便您可以修复它，它会代表您默默地插入一个不同的委托，为您修复类型.一方面，这是一种很好的做我的意思而不是我说的"功能，在该代码中，它看起来应该可以正常工作.另一方面，很意外的是，您要求从通知"方法中创建一个委托，而您返回的委托绑定到一个完全不同的方法，它是一个通知"的代理.

Incidentally, if you try to pull these sorts of conversion shenanigans in Visual Basic, it will cheerfully allow you to. VB will do the equivalent of the last thing; it will detect that there is a type mismatch and rather than telling you about it so that you can fix it, it will silently insert a different delegate on your behalf that fixes up the types for you. On the one hand, this is a nice sort of "do what I mean not what I say" feature, in that code that looks like it ought to work just works. On the other hand, it is rather unexpected that you ask for a delegate to be made out of the method "Notify", and the delegate you get back out is bound to a completely different method that is a proxy for "Notify".

在 VB 中，设计理念更多地是默默地纠正我的错误并按照我的意思去做".在 C# 中，设计理念更多地是告诉我我的错误，以便我自己决定如何修复它们".两者都是合理的哲学；如果您是那种喜欢编译器为您做出正确猜测的人，您可以考虑研究 VB.如果您喜欢编译器提醒您注意问题而不是猜测您的意思，那么 C# 可能更适合您.

In VB, the design philosophy is more on the "silently fix my mistakes and do what I meant" end of the spectrum. In C# the design philosophy is more on the "tell me about my mistakes so I can decide how to fix them myself" end. Both are reasonable philosophies; if you are the sort of person that likes when the compiler makes good guesses for you, you might consider looking into VB. If you're the sort of person who likes it when the compiler brings problems to your attention rather than making a guess about what you meant, C# might be better for you.

这篇关于为什么接口不起作用，但抽象类可以使用泛型类约束?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！