.NET中每个文件规则一个类？

Question

我遵循这条规则，但我的一些同事不同意这一点，并认为如果一个类较小，它可以与其他类保留在同一个文件中。

我一直听到的另一个论点是“即使微软不这样做，我们为什么要这样做？”

对此有何普遍共识？是否有应避免的情况？

Answer 1

当人们在绝对中思考，并且说你不应该这样做或那些主观和挑剔的东西时，我讨厌它，好像我们都需要遵循一些愚蠢的对与错的想法。 底线：如果有意义的话，每个文件有多个类是完全没问题的。有道理我的意思是：

1. 使代码更容易消化和 保持
2. 使解决方案不那么烦人 （滚动无数
。不必要的文件）
3. 开发团队没问题 它作为一种本地编码实践

为什么我可能希望每个文件有多个类的一个很好的例子：

假设我有几十个自定义异常类，每个类都是一个4行，我可以为每个单独分配一个文件，或者我可以对异常进行分组并为每个组分配一个文件。对我来说，似乎最合理/最实用的方法是对它们进行分组，并且只有几个文件，因为它更有效的时间/编码（我不必右键单击 - ＆gt;添加类，重命名，50次），它使解决方案不那么混乱，表现更好。

Answer 2

每个文件一个类还可以让您更好地了解每个签入的更改，而无需查看文件的差异。

Answer 3

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Answer 4

如果文件紧密耦合并且其中至少有一个非常小，我有时会在一个文件中组合多个类。

一般'最佳做法'是每个班级有一个文件。

Answer 5

除了假设的论点，而是专注于使用Visual Studio IDE和不断增长的软件项目的Windows .NET，在这种情况下，每个文件只有一个类是有意义的。

---

一般来说，用于视觉参考每个文件没有任何东西可以胜过一个类。真。

我不知道微软是否做同样的事情，但是他们确实创建了partial keyword来将多个文件分成一个类（这更严重） 。它通常用于将自动生成的设计器代码与同一类中的自定义代码分开（但有时用于允许不同的开发人员通过不同的文件同时处理该类）。因此，Microsoft确实看到了多个文件的好处，并且每个人都有多个文件组织的想法，确保使用.NET。

对于嵌套类，您别无选择，只能使用一个文件，或者至少使用其中的类的第一部分。一个文件是必要的，在这种情况下很好：

class BicycleWheel {
    class WheelSpoke {
    }
}

否则为什么要在一个文件中保留多个类？参数“因为它们很小”或彼此相关 并没有多少水因为最终你的课程会与其他人联系在一起类。 最终，您无法根据其使用情况轻松推断对象的文档内组织，尤其是在软件持续增长的情况下。

此外，如果您使用文件夹作为名称空间，那么您将永远不会有类文件名冲突。当不在像Visual Studio这样的开发环境中时，在文件系统上按文件名定位类也很方便（例如如果你想用记事本快速编辑类或快速/轻快的话< /强>）。

有很多好理由......

Answer 6

在绝大多数情况下，我遵循每个文件规则的一个类。我经常做的唯一例外是与特定类紧密耦合的枚举的定义。在这种情况下，我会经常在该类的文件中包含枚举的定义。

Answer 7

我也相信单个文件中应该包含一种类型。

必须提到此规则有一个例外：有两个类只有通用参数不同的类，例如：

RelayCommand     

和

RelayCommand<T>

Answer 8

无论内容多么轻巧，我认为每个文件都有一个类/接口/等等。

如果我正在使用Visual Studio中的大型解决方案，我希望能够看到这些文件，而不必深入研究。即使使用像ReSharper这样的导航工具，我也需要1：1的映射。

如果您发现很多内容很少或没有内容的源文件（可能会扩展一个类但不添加任何内容），那么您可能应该重新考虑您的设计。

Answer 9

真的，这归结为个人偏好。每个人都会说“每个档案一个班级”，但我们都有理由在某些情况下避免这种情况。我曾经有一个大型项目，有大约300个不同的枚举。当一些枚举只是三态时，我不会有300个单独的文件，每个类一个。

对于那些找不到某些类的人，如果他们不是全部都是以他们的名字命名的文件，那么你是否有理由不使用Find查找整个解决方案？使用Find节省了我滚动浏览解决方案资源管理器的宝贵时间。

Answer 10

我发现在同一个文件中使用标准工厂类对类进行分组非常有用。

Answer 11

我通常每个文件都有一个类，但您通常需要自行决定是否可以包含相关的类，例如将您的异常分组，可以由您自己和其他开发人员重复使用。在这种情况下，用户只需要包含一个文件而不是多个文件。

所以重点是：谨慎应该使用!!!

Answer 12

C＃的StyleCop工具具有标准规则，在一个命名空间中需要不超过一个顶级类（以及该命名空间中的任意数量的接口，委托和枚举）。

如果两个或多个类中第二个和后续类只被第一个使用，那些可以而且应该是内部类，只对消费类可见。

Answer 13

在更大的解决方案中，我认为每个文件有一个类并且文件名称与类相同是非常有价值的。它使您可以更轻松地找到需要使用的代码。

Answer 14

有时每个文件有一个类，但 ...

当多个类严格相关时，同一源文件中的多个类是IMHO， BETTER ，而不是将短源文件专用于每个类。源代码更具可读性和紧凑性（使用#region，相同的源可以比以前更加结构化）。

还要考虑有时它是 NECESSARY 将相同的类分布在不同的文件中（使用 partial ），因为拥有20000+行源文件并不方便RAM我有空（但这是另一个问题）。

Answer 15

这真的是个问题吗？:) 真正的小班，就像枚举，可以与其他人一起。要遵循一条规则：只将具有共同点的类放在一起。

作为一个题外话 - 在我的一个项目中，我有一个内部有150个课程的文件。该文件有10000行代码。但它是自动生成的，所以它完全可以接受：）

Answer 16

有时我会把一个小班留在一个更大的班级，但前提是他们与一个对象非常紧密相关，而且它是集合类或工厂。

但是有一个问题。最终，小班增长到它应该在自己的文件中，如果你将它移动到新文件，你将失去对修订历史的轻松访问。

即。

• 星期一，我在文件y.css
中对我的班级x和y进行了更改
• 在星期二我将类x分隔到它自己的文件x.css，因为它已经变大了
• 周三，我的老板希望看到我在星期一在x级看到的变化，所以他查看了x.css的历史记录，只有x.css在星期二变化之前没有显示历史记录。

Answer 17

在一个文件中放置多个相关类的一个原因是，使用您的API的可怜的混蛋不必花半天时间输入导入声明样板和那个糟糕的混蛋谁必须维护代码不必花费半天滚动导入声明样板。我的经验法则是，如果你几乎总是同时使用它们的大部分，而不是一次只使用一个，那么多个类属于同一个文件。

Answer 18

每个文件的一个类的另一个投票，该文件的名称与该类相同。对我而言，它有助于长期可维护性。我可以轻松查看存储库，看看哪些类是解决方案的一部分，而无需打开项目或任何文件。

Answer 19

我99％的时间跟着它。遵循标准很好，但我也相信灵活性有其自身的地位。有时，把事情分开似乎只是浪费时间。在那些时候，我克服自己，只写我的代码。

Answer 20

我这样做，但只有当这些类以子父方式相关并且子类仅由父级使用时。

Answer 21

到目前为止，响应似乎围绕着人们对规则的例外，所以这是我的：在.NET3.5 SP1中使用DataAnnotations包时，我将类及其元数据“伙伴”类保持在一起。否则，它们总是处于单独的文件中。你知道，大多数时候。除非他们不是。

Answer 22

我很少这样做。例如，如果有一个与该类密切相关的枚举或结构，但这个枚举或结构太过微不足道，无法单独分离。

或者单独的类包含该主类的一些扩展方法。

Answer 23

我通常坚持每个文件一个类。但是我将为项目范围内使用的类似结构组制作例外。例如：

• 包含任何EventArgs子类的EventArgs.cs，因为它们通常只有5-10行代码，但它们通常由几个不同的类使用。或者，我可以将EventArgs类放在与声明事件的类相同的文件中。
• 一个Delegates.cs，其中包含整个项目中使用的代理，因为它们通常每个只有一行。同样，另一种方法是将它们与暴露/使用它们的类放在同一个文件中。
• 包含整个项目中使用的enum的Enums.cs。 （如果有enum仅由一个班级使用，我通常会将其private加入该班级。）

Answer 24

我喜欢创建较小的类并确保该类只执行它应该执行的操作的想法。如果您有多个有助于解决单个问题的类，那么将它们放在同一个文件中没有任何害处。

我不会遵循MS惯例，因为它们不是最好的做法！

Answer 25

One case could be:当您的班级共同组成一个module / unit时，它会为某些主要课程提供服务 比如helper classes，其他明智的没有。

查看ASP.NET MVC 2.0项目源代码。它严格遵循这条规则

Answer 26

来回非常有趣，而且似乎没有结果，尽管我的总体印象是类和文件之间的1-1映射是多数意见，尽管有一些逐个例外。

我很好奇你的答案是否有所不同取决于你是否：（1）开发Windows窗体应用程序，Web应用程序，图书馆等等;或（2）是否使用Visual Studio。在使用VS时，似乎每个文件规则的一个类也意味着每个VS项目有一个类，因为其他线程中的共识似乎是VS解决方案/项目应该在目录/文件命名和结构中进行镜像。实际上，我的印象是，共识是将项目名称=程序集名称=（嵌套）名称空间名称，然后所有这些名称将在目录/文件命名和结构中进行镜像。如果这些是正确的指导方针（或规则），那么所有这些看似正交的组织机制将保持同步。

Answer 27

是的，为了便于阅读，我们每个班级应该有一个文件！ 刚跳进一个项目。我在一个文件中看到很多类。它就是这样 一个新人很难理解它。我们不应该考虑可维护性吗？我们开发软件的时候？很多时候，其他开发人员将继续开发。 我们有命名空间来安排我们的东西，我们不需要文件来做那个！。

Answer 28

我没有看到其他人提到的另一点是，当您使用每个文件规则一个类进行开发时，您可以轻松查看该特定类在使用什么。

例如：您可能有两个类，其中一个类使用Linq，而另一个不使用Linq。

如果这些类在同一个文件中，则不查看代码就无法知道哪个类使用了什么。如果每个文件都是一个类，则只需查看文件顶部以查看该类中正在使用的内容即可。如果您要迁移到新的lib等目录，将有帮助。

Answer 29

到目前为止，尚未在答案中提及每个文件一个类的另一个原因是，每个文件一个类使得在代码审查期间更容易理解PR的影响。它还可以减少合并冲突。

当某人发布PR以获得反馈时，我可以查看更改的文件列表，并立即看到与我可能正在处理的文件有任何重叠之处。根据重叠情况，我可能想更深入地研究他们的代码或给它一个好的命令，因为我有信心它不会影响我自己的更改。

当两个人在一个多类文件中工作并且都添加了依赖项时，您很有可能在顶部的using块中遇到合并冲突。将这些类分为文件可将依赖项分开，这样您就可以看到每个类在使用什么，而不会出现这样的冲突。

此规则（接口+实现，枚举，...）有一些例外，但是比起相反的规则（它通常会让初级开发人员将所有无关类捆绑到同一文件中）相反，它是一个更好的起点。

每个文件一个类是一个明确的规则，无需解释。

---

文件中的相关类受个人偏好和解释的影响（如您从此处的所有其他答案中所见， 何时可以使用），因此这是一个很差的规则。

Answer 30

每个文件一个代码项，是的。

其他一切都是一种弊端 - 坦率地说，这是RAD受害者的一个迹象。

一旦开始正确的软件开发（IoC，设计模式，DDD，TDD等......）并离开“omg让我们完成这项工作，我不知道如何，但我得到报酬”操场，一个会看到这条规则确实非常重要。