一个程序员应该在一个文件中放多少类?

就个人而言,我建议每个文件一个类 除非 辅助类对文件中的主类是私有的。例如,C中的嵌套类将保留在父类文件中,但实用程序类 可以 在其他地方有用,可以分解成自己的文件甚至名称空间。

关键是要了解你的环境以及人们会在哪里寻找东西。如果有现成的方法论,在你打乱它之前要仔细考虑。如果您的同事希望相关的、紧密绑定的类在单个文档中,那么必须搜索它们可能会很烦人(尽管使用现代的IDES不应该是问题)。

另一个将内容分成更多文件而不是更少文件的原因是版本控制。如果您做了一个小的更改,它应该在可能的情况下只更改一个小文件。如果您做了一个彻底的更改,那么查看日志是显而易见的,因为会注意到受影响的所有文件(以及间接的类)。

我认为我使用过的所有OO语言的最佳实践是在一个文件中有一个类。我相信有些语言可能需要这个,但我不确定这个事实。但我想说的是,每个文件一个类,文件名与类名匹配(以及大部分与包结构匹配的目录结构)是最佳实践。

1类=2个文件。A.H和A.C,你们这些孩子真幸运:)

没有必须始终遵循的硬而快的规则(除非特定语言强制执行)。一个文件中只有一个类或多个类是有充分理由的。它确实取决于语言。

在C语言和Java语言中,每个类都倾向于坚持一个文件。

我会说C++,虽然我经常把多个类放在一个文件中。这些类通常都很小,而且非常相关。在某些通信协议中,每条消息都有一个类。在这种情况下,每个文件的一个文件意味着大量的文件,实际上比它们在一个文件中更难维护和读取代码。

在C++中,类的实现与类定义是分开的,因此每个类{/ 身体 /}比其他语言小,这意味着类的大小更便于在一个文件中分组。

在C++中,如果你正在编写一个库(例如标准模板库),你可以把所有的类放在一个文件中。用户只需要包含一个头文件,然后就可以得到所有类,这样他们就可以更轻松地使用这些类。

这是一种平衡。答案是任何最容易理解和维护的东西。默认情况下,每个文件都有一个类是有意义的,但是如果在一个文件中定义了一组相关的类,那么在很多情况下使用这些类更为实际。

我把课程放在同一个文件中,如果它们属于同一个文件,不管是出于技术上的原因还是美学上的原因。例如,在提供插件接口的应用程序中,类 插件 (插件的基类)和 插件管理器 我通常把它们放在同一个文件里。但是,如果文件太大,不适合我的口味,我会把它们分成单独的文件。

我注意到目前我主要用Python编写代码,这影响了我的设计。python在如何将东西划分为模块方面非常灵活,并且有很好的工具来管理事物的名称空间。例如,我通常将应用程序的所有代码放在一个python模块(一个目录 __init__.py )并让模块从子模块导入特定的名称。API就是这样的 applib.PluginManager 而不是 applib.pluginstuff.PluginManager .

这使得移动东西很容易,这也让我在设计时不那么挑剔:我以后总是可以修复东西。

一个类=一个文件。总是。除了一个类在C中=多个文件,或者一个类包含内部类等之外;)

我们的标准是每个文件一个。唯一的例外是,对于类和它的类型化集合,我们将它们放在一起。

随着时间的推移,我开始重新体验,“小班”总是倾向于成长。然后你会想把他们分开,把团队中的其他人(还有你自己)搞糊涂。

我试着为每个文件保留一个类(像上面大多数文件一样),除非它们是小类。如果有很多,我可以把它们分成不同的主题。但通常我只是把它们放在一个文件中,在编辑器中进行代码折叠。对于我的私人黑客来说,这对我来说是不值得的。

每个文件一个类似乎是标准的。这也是我通常做的方式。

有几次我偏离了这个方向。尤其是当一个较小的类是另一个类的成员时。例如,在设计数据结构时,我可能会在与“bigstructure”类相同的文件中实现“node”类。

在面向对象的语言中,对于将类分组为单个文件,您遵循什么准则?

这要看情况而定。在团队工作中,我努力遵循团队标准;在个人工作中,我更倾向于随遇而安。

在独角戏里,然后…

你总是给每个班一个单独的文件吗?您是否将紧密耦合的类放在一起?您是否在一个文件中指定了接口的两个实现?

不,有时。对。

您是基于实现可能有多少行代码,或者它在类的用户看来有多“杂乱”来实现的吗?或者用户更愿意把所有东西放在一个地方?

它主要基于:

• 导航有多简单?一个包含许多类的大型长源文件更为困难。
• 编辑有多简单?当编辑多个短的相关类时,如果它们都在一个带有拆分器的源文件中,可能比在多个源文件中更容易,因为我运行的文本编辑器一次最多显示一个源文件。

除非内部类是完全私有的,否则我更喜欢1比1。 即使这样,我通常也会把它分解出来,以便找到它并跟踪SVN中的变化。