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

Question

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

以下是 C++/CLI 标准的规定：

[注意：CLI 将非成员函数视为某些未命名类的成员； 但是，在 C++/CLI 源代码中，此类函数无法使用该类名显式限定。 尾注]

元数据中非成员函数的编码未指定。 [注意：这不会导致互操作问题，因为此类函数无法具有公共可见性。 尾注]

所以我的问题是为什么 C# 不实现这样的东西？ 或者您认为不应该有非成员函数并且每个方法都应该属于某个类？

我的观点是拥有非成员函数支持，这有助于避免污染类的接口。

有什么想法吗..？

Answer 1

更新：2009 年的这个问题已经被语言进化所取代。 自 C# 10 以来，该语言已支持类声明之外的顶级语句，从而使“为什么不”问题变得毫无意义。

---

请参阅此博客文章：

https://learn.microsoft.com/en-us/archive/blogs/ericlippert/why-doesnt-c-implement-top-level-methods

(...)

有人问我“为什么 C# 不实现功能 X？” 每时每刻。 答案总是一样的：因为没有人设计、指定、实施、测试、记录和交付该功能。 所有这六件事都是实现一项功能所必需的。 所有这些都花费了大量的时间、精力和金钱。 这些功能并不便宜，考虑到我们有限的时间、精力和金钱预算，我们非常努力地确保我们只提供那些能够为用户带来最大利益的功能。

我知道这样的笼统答案可能无法解决具体问题。

在这种特殊情况下，过去明显的用户利益不足以证明随之而来的语言复杂性是合理的。 通过严格不同的语言实体如何相互嵌套，我们（1）将法律程序限制为通用的、易于理解的风格，并且（2）使得定义可理解的、可指定的、可实现的、可测试的“标识符查找”规则成为可能并且可记录。

通过限制方法体始终位于结构或类内部，我们可以更轻松地推断调用上下文中使用的非限定标识符的含义； 这样的东西始终是当前类型（或基类型）的可调用成员。

(...)

以及此后续发布：

http://blogs.msdn.com/ericlippert/archive/2009/06/24/it-already-is-a-脚本语言.aspx

(...)

与所有设计决策一样，当我们面临许多相互竞争、引人注目、有价值且不可共存的想法时，我们必须找到可行的折衷方案。 我们不会这样做，除非考虑所有可能性，这就是我们在本例中所做的。

（来自原文的强调）

Answer 2

C# 不允许，因为 Java 不允许。

我可以想到 Java 的设计者可能不允许

• Java 被设计得简单的几个原因。 他们试图创造一种没有随机快捷方式的语言，这样你通常只有一种简单的方法来完成所有事情，即使其他方法会更干净或更简洁。 他们希望最小化学习曲线，学习“类可能包含方法”比“类可能包含方法，函数可能存在于类之外”更简单。
• 从表面上看，它看起来不太面向对象。 （任何不属于对象的东西显然都不能是面向对象的？可以吗？当然，C++ 说是，但 C++ 没有参与这个决定）

正如我在评论中已经说过的，我认为这是这是一个很好的问题，而且在很多情况下，非成员职能会更好。 （这部分主要是对所有其他答案说“你不需要它”的回应）

在允许使用非成员函数的 C++ 中，它们通常是首选，原因如下：

• 它有助于封装。 访问类的私有成员的方法越少，该类就越容易重构或维护。 封装是OOP的重要组成部分。
• 当代码不属于类时，可以更轻松地重用代码。 例如，C++ 标准库将 std::find 或 std::sort` 定义为非成员函数，以便它们可以在任何类型的序列上重用，无论是数组、集合、链表或（至少对于 std::find）流。 代码重用也是OOP的重要组成部分。
• 它为我们提供了更好的解耦。 find 函数不需要了解 LinkedList 类即可对其进行操作。 如果它被定义为成员函数，那么它将成为 LinkedList 类的成员，基本上将这两个概念合并为一个大 blob。
• 可扩展性。 如果您接受类的接口不仅仅是“其所有公共成员”，而且还包括“在该类上操作的所有非成员函数”，那么就可以扩展类的接口，而无需编辑或甚至重新编译类本身。

拥有非成员函数的能力可能起源于 C（在那里你别无选择），但在现代 C++ 中，它本身就是一个重要的功能，不仅是为了向后兼容的目的，而且因为更简单，它允许更干净、更可重用的代码。

事实上，C# 似乎很晚才意识到同样的事情。 您认为为什么要添加扩展方法？ 它们试图实现上述目标，同时保留简单的类似 Java 的语法。
Lambda 也是有趣的例子，因为它们本质上也是自由定义的小函数，而不是任何特定类的成员。 所以，是的，非成员函数的概念很有用，C# 的设计者也意识到了同样的事情。 他们只是试图从后门偷偷地引入这个概念。

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

Answer 3

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

Answer 4

不将每个方法放入命名类中有什么好处？ 为什么非成员函数会“污染”类的接口？ 如果您不希望它作为类的公共 API 的一部分，请不要将其公开或不要将其放入该类中。 您始终可以创建不同的类。

我不记得曾经想要编写一个没有适当范围的浮动方法 - 当然，除了匿名函数（它们实际上并不相同）。

简而言之，我看不到非成员函数有任何好处，但我可以看到将所有方法放入适当命名的类中在一致性、命名和文档方面的好处。

Answer 5

CLS（公共语言规范）规定，符合 CLS 的库中不应包含非成员函数。 它就像是除了 CLI（公共语言界面）的基本限制之外的一组额外的限制。

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

using System.Linq.Enumerable; // Enumerable is a static class

...

IEnumerable<int> range = Range(1, 10); // finds Enumerable.Range

这样就无需进行更改CLS 和现有库。

这些博客文章演示了一个用于 C# 函数式编程的库，它们使用只有一个字母长的类名，以尝试减少由于限定静态方法调用的要求而引起的噪音。 如果 using 指令可以针对类，这样的示例会变得更好一些。

Answer 6

自 Java 以来，大多数程序员很容易接受任何方法都是类的成员。 我没有制造任何相当大的障碍，也没有使方法的概念变得更加狭窄，这使得语言变得更容易。

然而，事实上，类推断对象，对象推断状态，因此类仅包含静态方法的概念看起来有点荒谬。

Answer 7

• 将所有代码都放在类中可以实现更强大的反射功能集。
• 它允许使用静态初始化器，它可以初始化类中静态方法所需的数据。
• 它通过显式地将方法封装在一个无法由其他编译单元添加的单元中来避免方法之间的名称冲突。

Answer 8

我认为您确实需要澄清您希望创建非成员静态方法来实现什么。

例如，您可能需要它们执行的某些操作可以使用 扩展方法 来处理

另一个典型的用途（仅包含静态方法的类）是在库中。 在这种情况下，在完全由静态方法组成的程序集中创建一个类没有什么坏处。 它将它们保持在一起，避免命名冲突。 毕竟，Math 中存在具有相同目的的静态方法。

另外，您不必将 C++ 的对象模型与 C# 进行比较。 C++ 很大程度上（但不是完全）与 C 兼容，而 C 根本没有类系统 - 因此 C++ 必须支持这种 C 遗留的编程习惯，而不是为了任何特定的设计命令。

Answer 9

看，其他编程语言很难从编译器的角度定义函数实例的内部性质。 在 Pascal 和 C 中，实例基本上被定义为只能作为指针处理的东西。 特别是，因为读/写可执行代码位置是九分之七的计算机科学教授坚决反对的。 作为类的成员，没有人需要关心如何对待其表现形式，因为该表现形式的类型是从类属性派生的。 可以创建像全局函数一样精确处理的东西：分配给变量的 lambda 函数：
<代码>

Func<int,int> myFunc = delegate(int var1)
{
    Console.WriteLine("{0}",var1*2);
    return var1*3;
};

. And it can simply be called like a global function by its variable name.
If so, the difference would be implementing a new object type on the lowest level with same behavior as another one. That is considered bad practice by experienced programmers, and was perhaps scrapped because of this.

Answer 10

请记住：C++ 是一种比 C# 复杂得多的语言。 尽管它们在语法上可能相似，但在语义上它们是非常不同的野兽。 你不会认为做出这样的改变会非常困难，但我可以看到它会怎样。 ANTLR 有一个很好的 wiki 页面，名为 是什么让语言问题变得困难？ 对于此类问题，最好咨询一下。 在这种情况下：

上下文敏感的词法分析器？ 除非您知道要解析什么样的句子，否则您无法决定要匹配什么词汇符号。

现在，我们不仅要担心类中定义的函数，还必须担心类外部定义的函数。 从概念上讲，没有太大区别。 但是在词法分析和解析代码方面，现在您遇到了一个额外的问题，即必须说“如果函数在类外部，则它属于这个未命名的类。但是，如果它在类内部，则它属于那个未命名的类”班级。”

另外，如果编译器遇到这样的方法：

public void Foo()
{
    Bar();
}

...它现在必须回答“Bar 是位于此类中还是全局类？”的问题。

转发或外部引用？ 即，需要多次通过？ Pascal 有一个“前向”引用来处理文件内过程引用，但通过 USES 子句等对其他文件中的过程的引用需要特殊处理。

这是导致问题的另一件事。 请记住，C# 不需要前向声明。 编译器将进行一次检查以确定哪些类被命名以及这些类包含哪些函数。 现在您必须担心查找类和函数，其中函数可以位于类内部或外部。 这是 C++ 解析器不必担心的事情，因为它会按顺序解析所有内容。

现在不要误会我的意思，它可能可以用 C# 完成，而且我可能会使用这样的功能。 但是，当您只需在静态方法前面键入类名时，真的值得克服这些障碍吗？

Answer 11

如果将自由函数与鸭子类型结合起来，它们将非常有用。 整个C++ STL都是基于它的。 因此，我确信 C# 在设法添加真正的泛型时将引入自由函数。

与经济学一样，语言设计也与心理学有关。 如果您通过 C# 中的自由函数激发了对真正泛型的兴趣而不交付，那么您就会杀死 C#。 然后，所有 C# 开发人员都会转向 C++，但没有人希望这种情况发生，C# 社区也不希望，更肯定那些投资于 C++ 的人也不希望这种情况发生。

Answer 12

虽然您确实需要一个类（例如名为 FreeFunctions 的静态类）来保存此类函数，但您可以自由地将 using static FreeFunctions; 放置在任何文件的顶部需要其中的函数，而不必在代码中添加 FreeFunctions. 限定符。
我不确定是否确实存在这种情况明显不如不要求函数定义包含在类中的情况。

Answer 13

Csharp 没有非成员函数，因为它复制或受到 java 哲学的启发，即只有 OOP 才能解决所有问题，并且它只允许使用 OO 方式解决问题。

如果我们真的想做泛型编程，非成员函数是非常重要的功能。 与将它们放在一个类中相比，它们更具可重用性。

由于缺少非成员函数，CSharp 必须提出 ExtensionMethods。

现在编程语言正在向函数式编程范式发展，它似乎是处理和解决问题的更好方法，也是未来。 CSharp 应该重新考虑一下。