与经典函数相比,代表成员的更多优点或缺点? [英] more advantages or disadvantages to delegate members over classic functions?

查看:27
本文介绍了与经典函数相比,代表成员的更多优点或缺点?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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 是一个委托.然而,在这种情况下,代表可以扮演类似的角色.

add_1 is a function whereas add_2 is a delegate. However in this context delegates can forfill a similar role.

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

Due to precedent and the design of the language the default choice for C# methods should be functions.

然而,这两种方法各有利弊,所以我列出了一个清单.这两种方法还有什么优点或缺点吗?

However both approaches have pros and cons so I've produced a list. Are there any more advanteges or disadvantages to either approach?

传统方法的优势.

  • 更传统的
  • 函数的外部用户看到命名参数 - 对于 add_2 语法 arg_n 和类型通常是不够的信息.
  • 与智能感知 - ty Minitech 配合使用效果更好
  • 使用反射 - ty Minitech
  • 使用继承 - ty Eric Lippert
  • 有一个这个" - ty CodeInChaos
  • 较低的开销、速度和内存 - ty Minitech 和 CodeInChaos
  • 在更改和使用函数方面不需要考虑 publicprivate.- ty CodeInChaos
  • 较少动态,较少允许在编译时未知 - ty CodeInChaos

委托类型字段"方法的优势.

Advantages to "field of delegate type" methods.

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

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

Please don't vote to close, thats happened already and it got reopened. It's a valid question even if either you don't think the delegates approach has much practical use given how it conflicts with established coding style or you don't like the advanteges of delegates.

推荐答案

首先,对于我来说,关于这个设计决策的高阶位"是我永远不会用 做这种事情公共字段/方法.至少我会使用属性,甚至可能不会.

First off, the "high order bit" for me with regards to this design decision would be that I would never do this sort of thing with a public field/method. At the very least I would use a property, and probably not even that.

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

For private fields, I use this pattern fairly frequently, usually like this:

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

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

and now I can very easily test the performance characteristics of different memoization strategies without having to change the text of ActualFunction at all.

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

Another advantage of the "methods are fields of delegate type" strategy is that you can implement code sharing techniques that are different than the ones we've "baked in" to the language. A protected field of delegate type is essentially a virtual method, but more flexible. Derived classes can replace it with whatever they want, and you have emulated a regular virtual method. But you could build custom inheritence mechanisms; if you really like prototype inheritance, for example, you could have a convention that if the field is null, then a method on some prototypical instance is called instead, and so on.

method-are-fields-of-delegate-type 方法的一个主要缺点当然是重载不再有效.字段的名称必须是唯一的;方法仅在签名中必须是唯一的.此外,您不会像我们获取泛型方法那样获取泛型字段,因此方法类型推断将停止工作.

A major disadvantage of the methods-are-fields-of-delegate-type approach is that of course, overloading no longer works. Fields must be unique in name; methods merely must be unique in signature. Also, you don't get generic fields the way that we get generic methods, so method type inference stops working.

这篇关于与经典函数相比,代表成员的更多优点或缺点?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆