在面向对象的语言中,您将类分组到单个文件中的指导原则是什么?你总是给每个班级一个单独的档案吗?你把紧密耦合的课程放在一起吗?您是否曾在一个文件中指定了几个接口实现?你是根据实现可能有多少行代码或者它对类的用户看起来"混乱"的方式来做的?或者用户是否愿意将所有东西放在一个地方?
就个人而言,我建议每个文件一个类,除非辅助类是文件中主类的私有类.例如,C#中的嵌套类将保留在父类文件中,但在其他地方可能有用的实用程序类会被分解为它们自己的文件甚至名称空间.
关键是要了解您的环境以及人们寻找事物的位置.如果已经建立了既定的方法,那么在你不高兴之前要仔细考虑.如果你的同事希望相关的,紧密绑定的类将在一个文档中,那么必须搜索它们可能会很烦人(尽管使用现代IDE它不应该是一个问题).
将内容分解为更多文件而不是更少文件的另一个原因是版本控制.如果进行小的更改,则应尽可能仅更改小文件.如果您进行彻底的更改,很明显会查看日志,因为会记录受影响的所有文件(以及间接的类).
我认为我用过的所有OO语言的最佳实践是在一个文件中有一个类.我相信有些语言可能需要这个,但我不确定这个事实.但我会说每个文件一个类,并且匹配类名称的文件名(以及与大多数部分匹配包结构的目录结构)是最佳实践.
1个类= 2个文件.一个.h和一个.c,你的孩子真是太幸运了:)
没有必须始终遵循的硬性规则(除非特定语言强制执行).只有一个类或在文件中有多个类是有充分理由的.它确实取决于语言.
在C#和Java中,人们倾向于坚持每个类一个文件.
我会说在C++中虽然我经常在一个文件中放置多个类.这些课程通常很小而且非常相关.例如.某些通信协议中每个消息的一个类.在这种情况下,每个文件的文件意味着很多文件,实际上维护和读取代码比在一个文件中更难.
在C++中,类的实现与类定义是分开的,因此每个类{/ body /}都小于其他语言,这意味着类的大小更方便,可以在一个文件中组合在一起.
在C++中,如果您正在编写库(例如标准模板库),则可以将所有类放在一个文件中.用户只需要包含一个头文件,然后他们就可以获得所有类,因此它们更容易使用.
有一个平衡.答案是最容易理解和维护的东西.默认情况下,每个文件都有一个类是有意义的,但是如果在一个文件中定义了一组相关的类,那么在很多情况下使用它们更为实际.