为什么C#不允许像C ++这样的非成员函数

C#将不允许编写非成员函数,每个方法都应该是类的一部分。 我认为这是所有CLI语言的限制。 但是我错了,我发现C ++ / CLI支持非成员函数。 编译时,编译器会使该方法成为某个未命名类的成员。

这是C ++ / CLI标准所说的,

[注:非成员函数被CLI视为某些未命名类的成员; 但是,在C ++ / CLI源代码中,这样的函数不能用该类名显式限定。 尾注]

元数据中非成员函数的编码是未指定的。 [注意:这不会引起互操作问题,因为这些function不能公开显示。 尾注]

所以我的问题是为什么不C#实现这样的东西? 或者你认为不应该有非会员职能,每种方法都应该属于某一类?

我的意见是有非会员function支持,这有助于避免污染类的界面。

有什么想法吗..?

C#不允许它,因为Java不允许它。

我可以想到Java的devise者为什么不允许它的几个原因

  • Java的devise很简单。 他们试图做一种没有任何快捷键的语言,所以通常只有一种简单的方法来做所有事情,即使其他方法更简洁也更简洁。 他们想要最小化学习曲线,而学习“一个类可能包含方法”比“一个类可能包含方法,function可能存在于类之外”更简单。
  • 从表面上看,它看起来不太面向对象。 (任何不属于对象的东西显然不可能是面向对象的吗?当然,C ++是肯定的,但C ++并没有参与这个决定)

正如我在评论中已经说过的,我认为这是一个很好的问题,有很多情况下,非成员函数会更好。 (这部分主要是回答所有其他答案,说:“你不需要它”)

在C ++中,非成员函数是允许的,他们通常是首选的,原因如下:

  • 它有助于封装。 访问类的私有成员的方法越less,类就越容易重构或维护。 封装是OOP的重要组成部分。
  • 当代码不是一个类的一部分时,代码可以更容易被重用。 例如,C ++标准库将std::find或std :: sort定义为非成员函数,以便它们可以在任何types的序列上重用,无论是数组,集合,链表还是(对于std: :至lessfind)stream。 代码重用也是面向对象的重要组成部分。
  • 它给了我们更好的解耦。 find函数不需要知道LinkedList类为了能够在它上面工作。 如果它被定义为一个成员函数,它将是LinkedList类的成员,基本上将这两个概念合并成一个大块。
  • 可扩展性。 如果您接受某个类的接口不仅仅是“其所有公共成员”,而且还包括“对类进行操作的所有非成员函数”,那么就可以扩展一个类的接口而不必编辑或甚至重新编译类本身。

具有非成员函数的能力可能源自于C(在这里你没有别的select),但是在现代C ++中,它本身是一个重要特征,不仅仅是为了向后兼容,而是因为更简单,它允许更清洁和更可重用的代码。

事实上,C#似乎已经实现了很多相同的事情,很久以后。 你为什么认为扩展方法被添加? 他们试图达到上述目的,同时保留简单的类似Java的语法。 羔羊也是一个有趣的例子,因为它们本质上也是自由定义的小函数,而不是任何特定类的成员。 所以是的,非成员函数的概念是有用的,C#的devise师已经实现了同样的事情。 他们只是试图通过后门偷偷摸摸的概念。

http://www.ddj.com/cpp/184401197和http://www.gotw.ca/publications/mill02.htm是由C ++专家撰写的关于这个主题的两篇文章。

非成员函数是一件好事, 因为它们改进了封装并减less了types之间的耦合。 大多数现代编程语言如Haskell和F#都支持自由函数。

没有把每个方法放在一个命名类中有什么好处? 为什么非成员函数会“污染”类的接口呢? 如果你不想把它作为一个类的公共API的一部分,或者不要公开它,或者不把它放在那个类中。 你总是可以创build一个不同的类。

我不记得曾经想写一个没有适当范围的方法 – 除了匿名函数(当然不是这样)。

总之,在非成员函数中我看不到任何好处,但是在将所有方法放在一个恰当命名的类中,我可以看到一致性,命名和文档方面的好处。

CLS(通用语言规范)说,你不应该在符合CLS的库中拥有非成员函数。 这就像一个额外的限制,除了CLI(公共语言接口)的基本限制。

未来的C#版本可能会添加写入using指令的function,该指令允许在没有类名限定的情况下访问类的静态成员:

 using System.Linq.Enumerable; // Enumerable is a static class ... IEnumerable<int> range = Range(1, 10); // finds Enumerable.Range 

那么就不需要改变CLS和现有的库了。

这些博客文章演示了一个用C#进行函数式编程的库 ,它们使用一个只有一个字母长的类名,试图减less静态方法调用的要求所造成的噪音。 如果using指令可以定位类,这样的例子会更好一点。

自Java以来​​,大多数程序员都轻易地接受任何方法都是类的成员。 我没有制造任何重大的障碍,使方法的概念更加狭隘,使语言更容易。

然而,事实上,类推断对象,对象推断状态,所以只包含静态方法的类的概念看起来有点荒谬。

  • 将所有代码放在类中,可以提供更强大的reflectionfunction。
  • 它允许使用静态初始化器,它可以初始化类中静态方法所需的数据。
  • 它避免了方法之间的名称冲突,通过明确地将它们包含在一个不能被另一个编译单元添加的单元中。

我想你真的需要澄清一下你想创build非成员静态方法来实现。

例如,您可能需要的一些东西可以使用扩展方法来处理

另一个典型的使用(只包含静态方法的类)在库中。 在这种情况下,在完全由静态方法组成的程序集中创build类几乎没有什么坏处。 它使它们保持在一起,避免命名冲突。 毕竟,math中有静态的方法可以达到同样的目的。

另外,您不一定要将C ++的对象模型与C#进行比较。 C ++在很大程度上(但不是完全)与C兼容,C根本没有类系统 – 所以C ++必须支持C语言的编程习惯,而不是为了任何特定的devise要求。

记住一点:C ++是比C#复杂得多的语言。 尽pipe它们在语法上可能相似,但它们在语义上却是非常不同的。 你不会认为做这样的改变是非常困难的,但我可以看到它是如何的。 ANTLR有一个很好的wiki页面,叫什么使语言问题变得困难? 这是很好的咨询这样的问题。 在这种情况下:

上下文敏感的词法分析器? 除非你知道你正在parsing什么样的句子,否则你不能决定匹配什么词汇符号。

现在,不用担心类中定义的函数,我们不得不担心在类之外定义的函数。 从概念上讲,没有太大的区别。 但是从代码的分析和parsing来看,现在还有一个额外的问题,就是如果一个函数在类之外,它就属于这个未命名的类,但是如果它在类中,那么它属于类。”

另外,如果编译器遇到这样的方法:

 public void Foo() { Bar(); } 

…现在必须回答这个问题:“这个酒吧位于这个class级还是全球class级?”

转发还是外部引用? 也就是说,需要多个通行证? Pascal具有处理文件内过程引用的“前向”引用,但是通过USES子句等引用其他文件中的过程需要特殊的处理。

这是导致问题的另一件事。 请记住,C#不需要前向声明。 编译器将只进行一次传递,以确定哪些类被命名以及这些类包含哪些函数。 现在你不得不担心find类函数,这些函数可以是类内部的,也可以是外部的。 这是一个C ++parsing器不需要担心的问题,因为它会按顺序parsing所有内容。

现在不要误解我的意思,这可能是用C#完成的,我可能会使用这样的特性。 但是当你只需要在一个静态方法的前面input一个类名时,是否真的值得克服这些障碍的麻烦?

如果你考虑一下,反驳的观点是“为什么C ++不支持扩展方法” ,答案在于他们的devise目标。

C ++为您提供名称空间函数,您可以在任何对象上调用这些函数,以帮助您以某种方式“扩展”该对象。

我在C ++中使用名称空间函数的大部分时间是创build接受对象的函数,并且执行我不想放入类成员函数的function。

在C#中,您可以创build一个扩展方法来为您完成工作(大部分时间)。 对于剩下的情况,您将错过该function。

以下面的代码为例:

 template<typename T> unsigned int findCount(vector<T>& vec, T data){ unsigned int count = 0; for(auto val : vec) if(val == data) ++count; return count; } 

现在,如果我在我的类中需要某种function,我可以将其添加到类的名称空间,并使用它,而不会使用该函数“污染”我的类。

在C#中,可以使用扩展方法实现相同的目标:

 static class Extensions { public static uint FindCount<T>(this List<T> list, T data) { uint counts = 0; foreach (var item in list) if (item.Equals(data)) ++counts; return counts; } } 

而且他们两人的工作方式都很酷。 许多人会争论C ++缺less扩展方法,许多人会争论C#缺less名称空间函数。

我认为最好的方式是把这些语言与一些细节进行比较,因为它们是具有不同实现的不同语言。

正如你在你的问题中引用的那样,C ++ / CLI并没有“真正”支持名称空间成员函数,因为它添加了一个未命名的类来使用它们,它们绝不接近于C ++的实现,可能closures的方式看起来非常不同。

最后,function总是令人期待的,尽pipe我希望C#中的命名空间成员函数与C ++中的扩展方法一样多。 反正没什么。