分割成文件-分割多少？

如果我说我有一个层次结构的实体框架，而不是一个组件模型。类似于：（
是的，这是组成的）

武器->枪->自动枪- > MP44
或者，更经典的例子：
实体-> MovableEntity->敌人->步行敌人

为了可读性和组织性，您会将源/头文件分割多远？是最好去像Entity.cpp，MovableEntity.cpp，Enemy.cpp等，还是像Entity.cpp [包含实体和MovableEntity]和Enemy.cpp [包含敌人和WalkingEnemy]这样的方法更好？（或者以一种与语言无关的方式，是针对每个类的一个Enemy文件和一个Entity文件还是一个文件？）
此外，这是否会影响可读性和组织性？

这完全是优先事项。但是，我个人认为最好在更多文件方面犯错。Java需要每个文件一个类，例如，文件名与类名相同。他们会根据政策执行此操作以强制执行此良好做法（尽管您可以拥有基本上可以解决此问题的子类）。

同样，源代码控制系统非常擅长合并文件中的更改，但是如果您只处理完全独立的文件，那么麻烦就少了。您还可以更轻松地查看谁更改了哪个班级。假设另一个开发人员对文件AllEntities.h进行了更改；在打开文件并查看diff输出之前，您不知道确切地更改了哪个实体。

不过，将与类相关的小型结构和枚举分组到一个类的文件中非常好。如果您有仅由单个类使用的枚举，为什么将其拆分为自己的文件？只是把它们放在一起。但是，如果它被另一个类使用（即，另一个类成员是该枚举类型的），那就是时候给它自己的文件了。

C / C ++之外的许多语言都对文件施加了约束。Ricket提到了Java的“每个文件一个类”。Python使用文件作为名称空间；其他语言通常会照搬那些精神。

如果使用的是C或C ++，则包含更多的文件通常意味着每个文件的编译时间更长；另一方面，进行较小的更改时，更少的内容意味着更多的重新编译。由于枚举不能在C中进行前向声明，因此出于依赖性的考虑，应始终将它们放入仅包含其他枚举的头文件中。

否则，Java的“每个类一个文件”是合理的，但是很长一段时间以来，Java一直支持内部类（例如容器）及其迭代器的内部类。同样，在任何其他语言中，您可能希望每个标头使用一个占主导地位的记录/结构/类/类型/接口/ blob，但也可能决定包括相关的帮助器或容器。

（您不需要使用组件模型，但是如果您具有像这样深层次而又特定的类层次结构，则以后会讨厌自己。）