我问这个是因为我发现分发类定义是一个非常危险的特性,所以你不能确定你是否了解它。即使我找到了三个部分定义,我怎么知道某处没有第四个?
我是 C# 的新手,但已经用 C++ 工作了 10 年,也许这就是我动摇的原因?
无论如何,“部分”概念必须有一些很大的好处,我显然错过了。我很想了解更多关于它背后的哲学。
编辑:对不起,在搜索现有帖子时错过了这个重复。
我问这个是因为我发现分发类定义是一个非常危险的特性,所以你不能确定你是否了解它。即使我找到了三个部分定义,我怎么知道某处没有第四个?
我是 C# 的新手,但已经用 C++ 工作了 10 年,也许这就是我动摇的原因?
无论如何,“部分”概念必须有一些很大的好处,我显然错过了。我很想了解更多关于它背后的哲学。
编辑:对不起,在搜索现有帖子时错过了这个重复。
使用代码生成时,部分类很方便。如果您想修改生成的类(而不是从它继承),那么在重新生成代码时,您将面临丢失更改的风险。如果您能够在单独的文件中定义额外的方法等,则可以重新创建类的生成部分,而无需对您手工制作的代码进行核对。
最大的好处是隐藏计算机生成的代码(由设计者)。
Eric Lippert 最近有一篇关于部分关键字的博文。
另一种用法是为嵌套类提供自己的文件。
两个人编辑同一个类,自动生成的设计器代码是我可以看到的两个直接功能,它们已通过部分类和方法解决。
与 1.1 相比,在单独的文件中使用设计器生成的代码要容易得多,在 1.1 中,您的代码通常会被 Visual Studio(在 Windows 窗体中)破坏。
Visual Studio 仍然在将设计器文件、隐藏代码和设计文件与 ASP.NET 同步方面搞得一团糟。
另一点是,当一个类实现多个接口时,您可以将接口实现拆分到不同的文件上。
所以每个代码文件只有属于接口实现的代码。它是根据关注点分离的概念。
如果您有某种荒谬的大类,由于某种原因无法或不允许在逻辑上分解成更小的类,那么您至少可以在物理上将它们分成多个文件,以便更有效地使用它。本质上,您可以一次查看小块,避免上下滚动。
这可能适用于遗留代码,这些代码可能由于一些神秘的政策而不允许与现有的 API 混淆,因为存在大量和根深蒂固的依赖关系。
不一定是部分类的最佳使用,但肯定会为您提供一个替代选项来组织您可能无法以其他方式修改的代码。
也许为时已晚,但请让我也加上我的 2 美分:
*.在处理大型项目时,将一个类分布在单独的文件中允许多个程序员同时处理它。
*.您可以轻松地为 VS.NET 生成的类编写代码(用于扩展功能)。这将允许您编写自己需要的代码,而不会弄乱系统生成的代码