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

Joa*_*nge 181 .net c#

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

我一直听到的另一个论点是"即使微软不这样做,我们为什么要这样做?"

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

Jam*_*mes 250

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

  1. 使代码更容易消化和维护
  2. 使解决方案不那么烦人(滚动无数不必要的文件)并减慢速度
  3. 开发团队可以将其作为本地编码实践

一个非常好的例子,说明为什么我可能需要每个文件多个类:

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

  • 千.理解最佳实践的基本原理并在违反它们之前思考两次是很好的.斯拉夫人的坚持是邪恶的. (89认同)
  • *几十个自定义异常类*?这不是问题的真正根源吗?我不仅仅意味着在这里挑剔:我认为大多数时候人们想要将类合并到一个文件中,这是因为他们不必要地创建了太多类型.(话虽如此,也许有一个实际情况,几十个自定义异常类是有意义的).许多小型的无操作类通常是更大问题的标志. (19认同)
  • 我在很大程度上同意你的观点.但例外是一种特殊情况.因为正确构建的系统需要有适当的异常处理来处理产生合法错误的所有情况,所以我读过的大多数最佳实践文章强调需要创建特定的异常(有时你需要很多它们来涵盖大型项目的所有业务规则),这样你就不会最终捕获system.exception,这根本就不是正确的异常处理. (15认同)
  • 我同意你不应该在没有充分理由的情况下盲目地遵循一些准则,但是我不同意你应该在一个文件中有多个类的事实.对我来说,文件应该在类之后命名,不能包含多个文件.某些语言(java为one)会记录实际强制该类位于文件名与文件名匹配的文件中.对我而言,它让新手更容易导航,因此我相信每个文件的一个类是正确的做法 (6认同)
  • 保持每个文件一个类并保持文件名和类名同步是一种约定,就像命名变量一样.Visual Studio非常适合这种方法.源控制系统和在项目中间添加的开发人员更容易.他们将直观地搜索与类名匹配的文件名. (3认同)

Mar*_*ark 172

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

  • 我不完全确定这个特定的答案是如何回答原帖的问题.当然它提供了一个保持1级文件的理由(虽然Luca和Dykam提出了好的观点),但它没有反映普遍的共识或提供应该避免的情况. (43认同)
  • 同一文件中的更多类仅在一个操作中增强了相关类之间的差异. (4认同)
  • 适当的差异查看器允许您查看一个提交的所有差异. (3认同)
  • 如果您认为最佳实践理解它们仅适用于给定的上下文,则不存在最佳实践.正如其他响应所指出的,有时候这条规则实际上会创建较少的可维护代码.随着工具越来越好,这个规则实际上变得不那么重要,因为它更容易在项目中找到类和类型. (3认同)

Jer*_*ell 71

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

  • 在.NET中有这样的规则吗?我也会回复声明结果.:o (4认同)

Phi*_*off 50

我有时会在一个文件中组合多个类,如果它们是紧密耦合的,并且其中至少有一个非常小.

一般的"最佳实践"是每个班级有一个文件.

  • @The Matt:这叫做避免过度工程.如果你有一些紧密耦合的类并且解耦它们会增加很多复杂性,而不是它提供的实际灵活性,那么重点是什么? (37认同)
  • 有时我基本上喜欢这个类只使用的"数据"类,所以我通常将数据类放在与用户相同的文件中,因为datac-lass通常几乎没有逻辑本身,它看起来像一个浪费为它创建一个新文件. (8认同)
  • 如果你认识到它们是耦合的,你为什么不将它们分离? (7认同)
  • @TheMatt:解密:http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggervisualizerattribute.aspx模块之间的耦合很糟糕,但逻辑特性中的类之间的协作是不可避免的. (5认同)
  • @The Matt:有时会有辅助类,我认为它是可以接受的耦合.它们降低了另一个类的一部分的复杂性,但仍然促进了该类的非常特定的目的. (2认同)
  • @jordan,earlz:我说的正是这些类型的类 :-) 有时将类解耦是没有意义的。 (2认同)
  • 我自己有时也会这样做……尽管我现在通常在主类下创建子类来封装这种关系。例如,包含子节点的列表类型对象。 (2认同)
  • @dsimcha关键是要通过去耦来降低复杂性。您所指的“复杂性”必须在磁盘上的物理文件中导航,因为我们所讨论的只是类的物理位置。因此,我不清楚为什么在预期重用的情况下将两个类与同一个物理文件分开会增加复杂性。听起来更像是懒惰。出于这种原因,如果要避免更多文件,这就是您要避免的事情,则应将所有代码都放入一个文件中。 (2认同)

Joh*_*n K 25

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


通常,对于视觉参考,每个文件没有任何一个类.真.

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

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

class BicycleWheel {
    class WheelSpoke {
    }
}
Run Code Online (Sandbox Code Playgroud)

否则为什么要在一个文件中保留多个类?"因为它们很小"或相互关联 的论点没有多少水,因为最终你的课程将与其他课程相关联.最终,您无法根据其使用情况轻松推断对象的文档内组织,尤其是随着软件的不断增长.

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

这么多好理由......

  • 根据记录,嵌套类可以是“部分”http://msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx 出于好奇我查了一下。 (2认同)

Gre*_*g D 13

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


And*_*nea 12

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

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

RelayCommand     
Run Code Online (Sandbox Code Playgroud)

RelayCommand<T>
Run Code Online (Sandbox Code Playgroud)


Mic*_*ael 7

无论内容多么轻巧,我认为每个文件的一个类/接口/等是必不可少的.

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

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


Jas*_*n M 6

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

对于那些找不到某些类的人来说,如果他们不是全部都是以他们的名字命名的文件,那么你是否有理由不在整个解决方案中使用查找?使用Find节省了我滚动浏览Solution Explorer的宝贵时间.


Chr*_*ark 5

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

  • 是的,但是您希望您的应用程序结构依赖于第三方工具吗? (3认同)

Ste*_*ham 5

用于C#的StyleCop工具具有标准规则,在一个命名空间中需要不超过一个顶级类(以及该命名空间中的任意数量的接口,委托和枚举).

在两个或多个类的情况下,第二个和后续类只被第一个类使用,那些可以而且应该是内部类,只对消费类可见.

  • 当你说"一个名称空间中不超过一个顶级类"时,你的意思是在一个`namespace`块中,对吧? (2认同)

Rob*_*vis 5

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


小智 5

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

所以关键是:应该谨慎使用!!!