【发布时间】：2010-08-21 02:10:09
【问题描述】：
我听说过关于过度使用区域的坏事，但是在向我的类添加枚举时，我将它们放入类末尾的 #region "Enums" 中，并对结构甚至子类做同样的事情。
有没有更好/标准的方法来对类中的此类元素进行分组？
（注意：这被标记为 C#/VB，但其他语言可能存在相同的情况，例如 Java）
【问题讨论】：
标签： c# vb.net coding-style code-organization region
【发布时间】：2010-08-21 02:10:09
【问题描述】：
当然，合理的分组是使用单独的源文件。
对于超过几个屏幕的类，您可能应该为此类类提供一个单独的源文件。否则在源文件中查找各种类和其他项目可能会很困难。
对于语义相关且每个枚举都小到可以放在屏幕上的枚举集合，将它们放在一个文件中通常是有意义的——但是你应该根据所有的目的来命名文件这些枚举共享。如果您无法想出一个描述它们共性的尖锐名称，那么这可能表明您应该再次将它们分开。 （当然这一段同样适用于类和结构，但只适用于非常小的。）
请注意，即使是 nested 类/结构/枚举也可以放在 C# 中的单独源文件中 — 只需将外部类声明为 partial。
如果您有一个完整的类层次结构相关的派生类（子类），您甚至可以为每个这样的层次结构创建一个子目录。例如，在名为 Collections 的子目录中，您可能有一个名为 CollectionBase.cs 的文件用于抽象基类，而每个派生类都有一个单独的源文件。
【讨论】：
-
我为命名空间正下方的每个类使用单独的源文件，即使它很小，而且我的子类往往是小型的、特定用途的对象。而且我的大多数枚举只与一个类或一个类的方法有关系。部分类也是 VB 中的一个选项，这似乎是一个有效的观点。我认为部分类仅适用于 WPF，+1。
-
部分类最初是为了什么而发明的，这无关紧要。这是一个通用功能，您可以在任何有意义的地方使用。扩展方法和 lambda 表达式也是如此——它们是为 LINQ 发明的并不重要。
-
我只是想知道将类拆分为文件而不是区域有多么不同。反对区域的论点对文件的影响大致相同。
-
您能否将我们链接到博客文章或有关地区假定缺点的讨论？我没有听说过它们，我想了解它们。