关于c＃：委托不只是速记界面吗？

Are delegates not just shorthand interfaces?

假设我们有：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

interface Foo
{
bool Func(int x);
}

class Bar: Foo
{
bool Func(int x)
{
return (x>0);
}
}

class Baz: Foo
{
bool Func(int x)
{
return (x<0);
}
}

现在，我们可以将Bar和Baz折腾为Foos，并将其称为Func方法。

代表们简化了一点：

1
2
3
4
5
6
7
8
9
10
11

delegate bool Foo(int x);

bool Bar(int x)
{
return (x<0);
}

bool Baz(int x)
{
return (x>0);
}

现在，我们可以作为Foo代表在Bar和Baz周围折腾。

除了获得较短的代码外，委托的真正好处是什么？

有一点细微的差别，委托可以访问定义了它们的类的成员变量。在C＃中(不同于Java)，所有内部类都被认为是静态的。因此，如果您使用接口来管理回调，例如按钮的ActionListener。实现的内部类需要(通过构造函数)传递对包含类的部分的引用，该类在回调期间可能需要与之交互。代表没有此限制，因此减少了实现回调所需的代码量。

较短，更简洁的代码也是值得的。

从软件工程的角度来看，您是对的，代表与函数接口非常相似，因为它们为函数接口提供了原型。

它们也可以以相同的方式使用：与传递包含所需方法的整个类(而不是传递整个类)相比，您可以仅传递一个委托。这样可以节省大量代码，并创建更具可读性的代码。

而且，随着lambda表达式的出现，现在也可以轻松地对其进行快速定义，这是一个巨大的好处。尽管可以使用C＃动态地构建类，但实际上这是一个巨大的难题。

将两者进行比较是一个有趣的概念。从用例和代码结构的角度来看，我以前从未考虑过这些想法有多相似。

从调用者的角度来看，委托与具有单个方法的接口引用确实有很多共同点。

在第一个示例中，Baz和Bar是类，可以继承和实例化。在第二个示例中，Baz和Bar是方法。

您不能将接口引用仅应用于与接口协定匹配的任何类。该类必须显式声明它支持该接口。
您可以将委托引用应用于与签名匹配的任何方法。

您不能在接口协定中包含静态方法。 (尽管您可以将静态方法与扩展方法结合使用)。
您可以使用委托引用来引用静态方法。

可以将委托视为方法的接口，该接口定义方法必须具有什么样的参数和返回类型才能适合委托

您可以将委托作为函数中的参数传递(在技术上，委托在编译时可以成为对象，但这不是重点)。您可以(显然)将一个对象作为参数传递，但是随后您将该类型的对象与该函数绑定为参数。使用委托，您可以传递任何函数以在具有相同签名的代码中执行，而不管其来自何处。

不，委托用于方法指针。然后，可以确保与委托关联的方法的签名正确。