我遵循此规则,但我的一些同事不同意该规则,并争辩说,如果一个班级较小,则可以将其与其他班级放在同一文件中。
我一直听到的另一个论点是:“即使Microsoft也不这样做,那为什么还要这么做?”
对此有什么普遍共识?在某些情况下应避免这种情况?
我遵循此规则,但我的一些同事不同意该规则,并争辩说,如果一个班级较小,则可以将其与其他班级放在同一文件中。
我一直听到的另一个论点是:“即使Microsoft也不这样做,那为什么还要这么做?”
对此有什么普遍共识?在某些情况下应避免这种情况?
Answers:
每个文件一个类也可以使您更好地了解每次签入的变化,而无需查看文件的差异。
我讨厌人们绝对考虑时说,您绝对不应该这样或那样主观和挑剔地这样做,就像我们所有人都需要遵循某人对是非的愚蠢观念一样。底线:如果有意义的话,每个文件有多个类是完全可以的。我的意思是说:
一个很好的例子说明为什么我可能希望每个文件包含多个类:
假设我有几十个自定义异常类,每个异常类都是4个班轮,我可以为每个异常类创建一个单独的文件,也可以对异常进行分组,然后按组分组。对我来说,最合理/最实用的方法是将它们分组,并且只包含几个文件,因为这是更有效的时间/编码方式(我不必右键单击->添加类,重命名50次) ,它使解决方案更整洁,性能更好。
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
return (rule.Overhead(useCase)
< My.PersonalThresholds.ConformismVsPracticality);
}
如果它们紧密耦合并且至少其中一个很小,我有时会将一个以上的类分组到一个文件中。
一般的“最佳实践”是每个班级只有一个文件。
除了假设性的争论,而是将重点放在带有Visual Studio IDE的Windows .NET和不断发展的软件项目上,在这种情况下,每个文件只有一个类是有意义的。
通常,对于视觉参考而言,每个文件都胜过一类。真。
我不知道Microsoft是否做同样的事情,但是他们确实创建了将一个类拆分为多个文件的partial
关键字(甚至更严重)。它通常用于将自动生成的设计器代码与同一类中的自定义代码分开(但有时用于允许不同的开发人员通过不同的文件同时处理该类)。因此,Microsoft确实看到了多个文件的好处,并且使用.NET时,每个人都牢记多个文件组织的想法。
对于嵌套类,您别无选择,只能使用一个文件,或者至少使用其中的类的第一部分。在这种情况下,一个文件是必需的并且可以:
class BicycleWheel {
class WheelSpoke {
}
}
否则,为什么要在一个文件中保留多个类?“因为它们很小”或彼此关联 的说法没有多大用处,因为最终您的班级将与其他班级关联。最终,您无法根据对象的用途轻松推断文件的文件组织,尤其是随着软件的不断发展。
另外,如果您使用文件夹作为名称空间,则永远不会出现类文件名冲突的情况。当不在像Visual Studio这样的开发环境中时,在文件系统上按文件名查找类也很方便(例如,如果您要使用Notepad或quick / light之类快速编辑类)。
这么多的好理由...
partial
我提到的关键字的间接引用。
partial
msdn.microsoft.com/zh-cn/library/wa80x488(VS.80).aspx 。出于好奇,我对此进行了查找。
我也相信单个文件中应该包含一种类型。
必须提到此规则的一个例外:具有两个仅在通用参数方面不同的类,例如:
RelayCommand
和
RelayCommand<T>
1.cs for
Foo <T>和Foo 2.cs for
Foo <T,T1>。
Foo<T>
和Foo<U>
同一个命名空间内。但是,如果命名空间不同,则它们通常位于不同的文件夹中。因此,对于Foo<T>
和Foo<U>
它应该是富1.cs and for
富<U,T>`Foo`2.cs。但是每个文件仍然一个类。
确实,这归结为个人喜好。每个人都会说“每个文件一个类”,但是我们都有理由在某些情况下避免这种情况。我曾经有一个大型项目,其中包含约300个不同的枚举。当某些枚举仅是三态时,我将不会有300个单独的文件,每个类一个。
同样对于无法找到某些类的人(如果不是全部都以它们的名字命名),是否有理由不使用Find在整个解决方案中查找?使用查找为我节省了在解决方案资源管理器中滚动的宝贵时间。
我通常每个文件只有一个类,但是您通常必须谨慎决定文件是否可以包含相关的类,例如,对异常进行分组,这些异常可以由您自己和其他开发人员重复使用。在这种情况下,用户只需要包含一个文件,而不需要多个文件。
因此,重点是:应谨慎使用!!!
有时每个文件一个类,但是 ...
当多个类紧密相关时,恕我直言,同一个源文件中的多个类比为每个类指定一个简短的源文件更好。源代码更具可读性和紧凑性(并且使用#region可以比以前更加结构化同一源代码)。
想想也是,有时它是必要在不同的文件(使用传播同一类部分),由于具有20000+行源文件是不是很方便,即使与RAM我有可用的(但这是另外一个问题)。
有时候,我会把一个小班级和一个大班级放在一起,但前提是它们与对象和它的集合类或工厂紧密联系在一起。
但是,这有一个问题。最终,小类增长到了应在其自己文件中的位置,如果将其移至新文件,则无法轻松访问修订历史记录。
即。
very tightly related
类,并保留它,前提是它仅占用少量的屏幕空间,并且不会被其他任何类用于同一目的。
这真的有问题吗?:)
确实,像枚举一样,很小的类也可以与其他类放在一起。要遵循一个规则:仅将具有共同点的类放在一起。
题外话-在我的一个项目中,我有一个包含150个类的文件。该文件具有10000行代码。但是它是自动生成的,因此完全可以接受:)
放置多个的原因之一 相关内容的类放在一个文件中的是,使使用您的API的可怜的混蛋不必花半天的时间输入导入声明样板,而必须维护代码的可怜的混蛋不必花一半的时间。一天滚动浏览进口报关样板。我的经验法则是,如果您几乎总是同时使用它们的一个很大的子集,而不是一次只使用一个,则多个类属于同一文件。
我这样做,但是仅当这些类以子父形式关联并且子类仅由父类使用时才这样做。
我通常坚持每个文件一堂课。但是对于在项目范围内使用的类似构造的组,我将予以例外。例如:
EventArgs
类,因为子类通常只有5-10行代码,但是它们通常由几个不同的类使用。或者,我可以将这些EventArgs
类与声明事件的类放在同一文件中。enum
在整个项目中使用的。(如果有一个enum
仅由一个类使用,则通常会private
在该类中使用它。)到目前为止,响应似乎与人们对该规则的异常有关,所以这是我的:在.NET3.5 SP1中使用DataAnnotations包时,我将类及其元数据“伙伴”类放在一起。否则,它们将始终位于单独的文件中。您知道,大部分时间。除非不是。
One case could be:
当你的班级共同组成一个module / unit
服务于一些主要班级的时helper classes
,否则不行。
看一下ASP.NET MVC 2.0项目源代码。严格遵守此规则
我没有看到其他人提到的另一点是,当使用每个文件一个类的规则进行开发时,您可以轻松地看到该特定类在使用什么。
例如:您可能有两个班级,其中一个班级使用Linq,而另一个班级则不使用。
如果这些类在同一个文件中,则不查看代码就无法知道哪个类使用了什么。如果每个文件只有一个类,则只需查看文件顶部以查看该类中正在使用的内容即可。如果您要迁移到新的库等,则有帮助。
到目前为止,尚未在答案中提及每个文件一个类的另一个原因是,每个文件一个类可以更轻松地在代码审查期间理解PR的影响。它还减少了合并冲突。
当某人发布PR以获得反馈时,我可以查看更改的文件列表,并立即看到与我正在处理的文件有任何重叠之处。根据重叠的部分,我可能想更深入地研究他们的代码,或者给它一个好的命令,因为我很有信心它不会影响我自己的更改。
当两个人在一个多类文件中工作并且都添加了依赖性时,您很有可能using
在顶部的块中遇到合并冲突。将类分为文件可将依赖项分开,这样您就可以看到每个类在使用什么,而不会出现这样的冲突。
该规则有一些例外(接口+实现,枚举等),但是比起相反的规则(它通常让初级开发人员将所有无关类的方式捆绑到同一个文件中)相对更好。
每个文件一类是一个明确的规则,无需解释。
文件中的相关类受个人喜好和解释的影响(您可以从此处的所有其他答案中看到何时可以使用),因此这是一个很差的规则。
来回交互非常有趣,并且似乎没有定论,尽管我的总体印象是,在类和文件之间以1-1映射是多数意见,尽管有些人与人之间有例外。
我很好奇您的答案是否取决于您是否是:(1)开发Windows Forms应用程序,Web应用程序,库或其他工具;或(2)是否使用Visual Studio。在使用VS时,似乎每个文件一个类的规则也暗示每个VS项目一个类,因为其他线程的共识似乎是VS解决方案/项目应该镜像到目录/文件的命名和结构中。确实,我的印象是,共识是使项目名称=程序集名称=(嵌套)名称空间名称,然后将所有这些名称映射到目录/文件的命名和结构中。如果这些是正确的准则(或规则),那么所有这些看似正交的组织机制仍将保持同步。