委托成员比经典功能有更多的优点或缺点？

Question

class my_class
{
    public int add_1(int a, int b) {return a + b;}
    public func<int, int, int> add_2 = (a, b) => {return a + b;}
}

add_1 是一个函数，而 add_2 是一个委托。但是，在这种情况下，代表可以扮演类似的角色。

由于先例和语言的设计，C# 方法的默认选择应该是函数。

不过，这两种方法各有利弊，所以我制作了一份清单。这两种方法还有更多的优点或缺点吗？

传统方法的优势。

• 更传统的
• 函数的外部用户请参阅命名参数 - 对于 add_2 语法 arg_n 和类型通常没有足够的信息。
• 与 intellisense 配合使用效果更好 - ty Minitech
• 使用反射 - ty Minitech
• 使用继承 - ty Eric Lippert
• 有一个“this” - ty CodeInChaos
• 更低的开销、速度和内存 - ty Minitech 和 CodeInChaos
• 在更改和使用功能方面无需考虑公共\私有。 - ty CodeInChaos
• 较少动态，允许较少在编译时未知 - ty CodeInChaos

“委托类型字段”方法的优点。

• 更加一致，不是成员函数和数据成员，只是数据成员而已。
• 可以在外观和行为上像一个变量。
• 将其存储在容器中效果很好。
• 多个类可以使用同一个函数，就好像每个类都是成员函数一样，这将非常通用、简洁并且具有良好的代码重用性。
• 直接在任何地方使用，例如作为本地函数。
• 在与垃圾收集一起传递时可能效果很好。
• 更动态，在编译时必须知道的更少，例如，可能存在在运行时配置对象行为的函数。
• 好像封装了它的代码，可以组合和返工，msdn.microsoft.com/en-us/library/ms173175%28v=vs.80%29.aspx
• 函数的外部用户会看到未命名的参数 - 有时这很有帮助，尽管能够命名它们会很好。
• 可以更紧凑，在这个简单的示例中，例如可以删除返回值，如果有一个参数，也可以删除括号。
• 滚动您自己的行为，例如继承 - ty Eric Lippert
• 其他考虑因素，例如功能性、模块化、分布式（代码编写、测试或代码推理）等...

请不要投票关闭，这已经发生了，它已经重新打开。这是一个有效的问题，即使您认为委托方法没有太多实际用途，因为它与既定的编码风格有冲突，或者您不喜欢委托的优势。

Answer 1

首先，对我来说，关于这个设计决策的“高阶位”是我永远不会用 public 字段/方法做这种事情。至少我会使用 property，甚至可能不会。

对于私有字段，我经常使用这种模式，通常是这样的：

class C
{
    private Func<int, int> ActualFunction = (int y)=>{ ... };
    private Func<int, int> Function = ActualFunction.Memoize();

现在我可以非常轻松地测试不同记忆策略的性能特征，而无需更改 ActualFunction 的文本。

“方法是委托类型的字段”策略的另一个优点是，您可以实现与我们“融入”语言的代码共享技术不同的技术。委托类型的受保护字段本质上是一个虚拟方法，但更灵活。派生类可以用他们想要的任何东西替换它，并且您已经模拟了一个常规的虚拟方法。但是您可以构建自定义继承机制；例如，如果您真的喜欢原型继承，您可以约定如果该字段为空，则调用某个原型实例上的方法，以此类推。

methods-are-fields-of-delegate-type 方法的一个主要缺点是，当然，重载不再有效。字段名称必须唯一；方法只是在签名上必须是唯一的。此外，您不会像我们获得泛型方法那样获得泛型字段，因此方法类型推断停止工作。

Answer 2

在我看来，第二个比第一个绝对没有优势。它的可读性要低得多，效率可能较低（鉴于必须隐含Invoke）并且根本不简洁。更重要的是，如果你曾经使用过反射，它就不会显示为一种方法，所以如果你这样做来替换每个类中的方法，你可能会破坏一些看起来应该有效的东西。在 Visual Studio 中，IntelliSense 不会包含该方法的描述，因为您不能将 XML cmets 放在委托上（至少，与将它们放在普通方法上的方式不同）并且您不知道它们是什么无论如何都指向，除非它是只读的（但是如果构造函数改变了它呢？）并且它将显示为一个字段，而不是一个方法，这很令人困惑。

您真正应该使用 lambda 的唯一情况是在需要闭包的方法中，或者当它提供显着的便利优势时。否则，您只会降低可读性（基本上是我的第一段与当前段落相比的可读性）并破坏与 C# 以前版本的兼容性。

Answer 3

为什么默认情况下应避免将委托作为方法，以及有哪些替代方法：

学习曲线

以这种方式使用委托会让很多人感到惊讶。不是每个人都能理解委托，或者你为什么要换掉函数。似乎有一条学习曲线。一旦你通过它，代表看起来很简单。

性能和可靠性

以这种方式调用委托会降低性能。这是我默认使用传统方法声明的另一个原因，除非它在我的模式中启用了一些特殊功能。

还有一个执行安全问题。公共字段可以为空。如果你传递了一个带有公共字段的类的实例，你必须在使用它之前检查它是否不为空。这会伤害性能并且有点蹩脚。

您可以通过将所有公共字段更改为属性来解决此问题（无论如何，这是所有 .Net 编码标准中的规则）。如果有人试图分配 null，则在 setter 中抛出 ArgumentNullException。

程序设计

即使您可以处理所有这些问题，允许方法完全可变也违背了静态 OO 和函数式编程语言的许多设计。

在静态 OO 中，类型始终是静态的，动态行为是通过多态实现的。您可以根据其运行时类型了解类型的确切行为。这对于调试现有程序非常有帮助。允许在运行时修改您的类型会损害这一点。

在静态 OO 和函数编程范式中，限制和隔离副作用 is quite helpful 以及使用 fully immutable structures 是实现此目的的主要方法之一。将方法公开为委托的唯一目的是创建可变结构，这具有完全相反的效果。

替代品

如果您真的想始终使用委托来替换方法，您应该使用像 IronPython 这样的语言或其他构建在 DLR 之上的语言。这些语言将针对您尝试实现的范例进行工具和调整。您的代码的用户和维护者不会感到惊讶。

话虽如此，有些用途证明使用委托代替方法是合理的。您不应该考虑这个选项，除非您有一个令人信服的理由这样做，以解决这些性能、混乱、可靠性和设计问题。只有在得到回报时才应该这样做。

用途

• 对于私人会员，Eric Lippert's answer describes a good use: (Memoization)。

• 您可以以基于函数的方式将它用于implement a Strategy Pattern，而不需要类层次结构。同样，我会为此使用私人成员...

...示例代码：

public class Context
{
    private Func<int, int, int> executeStrategy;

    public Context(Func<int, int, int> executeStrategy) {
        this.executeStrategy = executeStrategy;
    }

    public int ExecuteStrategy(int a, int b) {
        return executeStrategy(a, b);
    }
}

• 我发现了一个特殊情况，我认为公共委托属性是有保证的：使用实例而不是派生类来实现 Template Method Pattern...

...这在需要大量设置/拆卸的自动化集成测试中特别有用。在这种情况下，将状态保存在旨在封装模式而不是依赖于单元测试夹具的类中通常是有意义的。通过这种方式，您可以轻松地支持在夹具之间共享测试套件的骨架，而无需依赖（有时是粗制滥造的）测试夹具继承。它也可能更适合并行化，具体取决于测试的实现。

var test = new MyFancyUITest
{
    // I usually name these things in a more test specific manner...
    Setup = () => { /* ... */ },
    TearDown = () => { /* ... */ },
};
test.Execute();

智能感知支持

函数的外部用户看到未命名的参数 - 有时这很有帮助，尽管能够命名它们会很好。

使用命名委托 - 我相信这至少会让您获得一些 Intellisense 参数（可能只是名称，不太可能是 XML 文档 - 如果我错了，请纠正我）：

public class MyClass
{
    public delegate int DoSomethingImpl(int foo, int bizBar);
    public DoSomethingImpl DoSomething = (x, y) => { return x + y; }
}

Answer 4

我会避免将委托属性/字段作为公共方法的方法替换。对于私有方法，它是一种工具，但不是我经常使用的工具。

• 实例委托字段具有每个实例的内存成本。对于大多数类来说可能是过早的优化，但仍然需要牢记。

• 您的代码使用公共可变字段，可以随时更改。这会损害封装性。

• 如果使用字段初始值设定项语法，则无法访问 this。所以字段初始化语法主要用于静态方法。

• 使静态分析更加困难，因为该方法的实现在编译时是未知的。

在某些情况下委托属性/字段可能有用：

• 某种处理程序。特别是如果多播（以及事件订阅模式）没有多大意义
• 分配的东西不能用简单的方法体轻松描述。比如一个记忆函数。
• 委托是运行时生成的，或者至少其值仅在运行时确定

Answer 5

对局部变量使用闭包是使用方法和私有字段的替代方法。我非常不喜欢有很多字段的类，特别是如果其中一些字段仅由两种或更少的方法使用。在这些情况下，在字段中使用委托可能比传统方法更可取

class MyClassConventional {
  int? someValue; // When Mark() is called, remember the value so that we can do something with it in Process(). Not used in any other method.
  int X;

  void Mark() {
    someValue = X;
  }

  void Process() {
    // Do something with someValue.Value
  }
}

class MyClassClosure {
  int X;

  Action Process = null;

  void Mark() {
    int someValue = X;
    Process = () => { // Do something with someValue };
  }
}

Answer 6

这个问题提出了一种错误的二分法——在函数和具有等效签名的委托之间。主要区别在于只有在没有其他选择的情况下才应该使用两者之一。在您的日常工作中使用它，它将被排除在任何代码审查之外。

上面提到的好处远远被几乎没有理由编写如此晦涩的代码的事实所抵消；尤其是当这段代码看起来你不知道如何编写 C# 时。

我敦促任何阅读本文的人忽略已陈述的任何好处，因为他们都被这样的代码证明你不知道如何用 C# 编程的事实所淹没。

该规则的唯一例外是，如果您需要其中一项福利，并且无法以任何其他方式满足该需求。在这种情况下，您需要编写比代码更多的注释来解释为什么您有充分的理由这样做。准备好像 Eric Lippert 一样清楚地回答。您最好能够像 Eric 那样解释您无法同时完成您的要求并编写可理解的代码。