更多的优点或缺点代表成员超过经典功能？ [英] more advantages or disadvantages to delegate members over classic functions?

问题描述

  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


• 适用于继承 - Eric Lippert


• 有一个这个CodeInChaos


• 降低开销，速度和记忆力Minitech和CodeInChaos


• 关于改变和使用功能的公共私人。 - ty CodeInChaos






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






• 更多一致，不是成员函数和数据成员，成员。


• 可以向外看起来像一个变量。


• 将它存储在容器中。


• 多个类可以使用相同的函数，因为它是每个成员函数，这将是非常通用，简洁和有良好的代码重用。


• 直接在任何地方使用，例如


• 更具动态性，在编译时必须知道的更少，例如，有一个局部函数。

<可以是在运行时配置对象行为的函数。

• 就像封装代码一样，可以组合和重做， msdn.microsoft.com/en-us/library/ms173175%28v=vs.80%29.aspx a>


• 这个函数的外部用户参见未命名的参数 - 有时候这是很有帮助的，虽然可以很好地命名它们。




• 滚动你自己的行为，比如继承 - ty Eric。如果没有一个参数，那么返回可以被删除。 Lippert


• 其他注意事项，例如功能，模块化，分布式，（代码编写，代码测试或推理）等...






请不要投票关闭，这已经发生，它已重新打开。这是一个有效的问题，即使你不认为代理方法有很多实际用途，因为它与已建立的编码风格冲突，或者你不喜欢代理的优势。

解决方案

首先，关于这个设计决定的我的高阶位将是，我永远不会做这样的事情与 public 字段/方法。至少我会使用属性，甚至可能不是。





对于私人字段，我经常使用此模式，通常如下：

  class C 
 {
 private Func< int，int> ActualFunction =（int y）=> {...}; 
 private Func< int，int> Function = ActualFunction.Memoize（）; 
  

现在我可以很容易地测试不同记忆策略的性能特征， ActualFunction at all。





方法是委托类型字段的另一个优点是你可以实现不同于我们的代码共享技术烤在语言。代理类型的受保护字段本质上是一个虚方法，但更灵活。派生类可以用任何他们想要的替换它，并且你已经模拟了一个常规的虚拟方法。但是你可以建立自定义继承机制;如果你真的喜欢原型继承，例如，你可以有一个约定，如果字段为null，那么将调用一个原型实例上的方法，等等。



<方法 - 代理类型方法的一个主要缺点是，当然，重载不再起作用。字段名称必须是唯一的;方法在签名中必须是唯一的。另外，你不能得到通用方法的方法，所以方法类型推理停止工作。



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 is a function whereas add_2 is a delegate. However in this context delegates can forfill a similar role.

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?

Advantages to conventional methods.

• more conventional
• outside users of the function see named parameters - for the add_2 syntax arg_n and a type is generally not enough information.
• works better with intellisense - ty Minitech
• works with reflection - ty Minitech
• works with inheritance - ty Eric Lippert
• has a "this" - ty CodeInChaos
• lower overheads, speed and memory - ty Minitech and CodeInChaos
• don't need to think about public\private in respect to both changing and using the function. - ty CodeInChaos
• less dynamic, less is permitted that is not known at compile time - ty CodeInChaos

Advantages to "field of delegate type" methods.

• more consistant, not member functions and data members, it's just all just data members.
• can outwardly look and behave like a variable.
• storing it in a container works well.
• multiple classes could use the same function as if it were each ones member function, this would be very generic, concise and have good code reuse.
• straightforward to use anywhere, for example as a local function.
• presumably works well when passed around with garbage collection.
• more dynamic, less must be known at compile time, for example there could be functions that configure the behaviour of objects at run time.
• as if encapsulating it's code, can be combined and reworked, msdn.microsoft.com/en-us/library/ms173175%28v=vs.80%29.aspx
• outside users of the function see unnamed parameters - sometimes this is helpfull although it would be nice to be able to name them.
• can be more compact, in this simple example for example the return could be removed, if there were one parameter the brackets could also be removed.
• roll you'r own behaviours like inheritance - ty Eric Lippert
• other considerations such as functional, modular, distributed, (code writing, testing or reasoning about code) etc...

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();

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.

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屋！