我正处于一个相对较大（10k +行）项目的规划阶段，该项目包含几个类（30+）和几个类继承（5 +）。
谢谢，
Advait
答案 0 :(得分：5)
1）是的。在大多数情况下，每个类别一个文件是个好主意。除非你有一个非常琐碎的类或抽象接口的集合，否则每个文件使用一个类。
2）尝试分开事物。通常在一个大项目中，你会有一些特定于某些部分的代码，其他代码对很多部分来说都很常见。那些使用非常有限的，只需保持“本地”。其他，放在包括dirs。
3）真的不需要。通常最好将密切相关的类（即文件）保持在一起;我会尝试将它们保持在一起，除非你在全局包含中有类似通用接口的东西，并且在模块目录中有特定的继承。
答案 1 :(得分：1)
1）这看起来更像Java类型 - 但是如果你的类不超过4行，那可能不是一个好主意。但是如果以后你想扩展一个已经存在的类，每个类的一个文件是个好主意。
2）这是你的选择，如何安排.h文件和.cpp文件。但是如果要将单个类放在一起，那么将相关的依赖放在一个地方似乎是合理的。
3）也许吧。但是将基类/接口放在中心部分并围绕它进行派生。
答案 2 :(得分：1)
- 每个课程应该有一个文件吗？我应该为每个继承分支都有一个文件夹吗？
感谢代码索引器，我经常忘记代码实际上在磁盘上的方式和位置。
对我来说每班的文件毫无意义。特别是在C ++中，我倾向于拥有许多小实用程序类。
通常：组件是目录。所有组件都位于同一个根目录下。 （这更令人遗憾的是，我必须使用make作为构建链。使用更好的构建系统，如SCons本身支持递归，这并不重要。）
我坚持可重用性，充分性和凝聚力的一般原则（按照Booch）进行分组。我经常将代码放入共享/静态库以便于集成到构建链中，因此，为了将类分组到组件/目录中，我使用的原理与用于在类中分组方法的原理非常相似。
- 我是否应该有一个包含我的头文件的'include'文件夹，或者我的头文件应该与我的.cpp / .c文件位于同一个文件夹中？
我个人更喜欢与源文件在同一目录中的标题。
值得注意的例外是定义组件公共接口的公共头。那些我放入include / compname / sudbirectory的那些：然后很容易看出我正在做/即将签到的更改会对其他组件产生影响。
显然，其他组件只允许包含$ ROOT / compname / include / compname /子目录中的标头。 （在include / make下包含compname / dir包含其他文件中的指令，看起来像#include "compname/headername.h"，这有助于提高可读性并防止标题名称冲突。）
- 我计划定期添加更多类（向继承树添加更多级别）。在树的最低级别，实现可能相对不相关但仍覆盖相同的虚函数。这些不相关的实现是否应该位于同一个文件夹中？
继承很少与文件的物理布局相关。
基类很少被修改，因为它们对业务逻辑几乎没有影响。顶级课程是逻辑的核心，很长一段时间它将由很多人来处理。因此，由许多组件重用的基本类应该拥有自己的组件。只是将它们移出视线。
这带来了另一个重点。有多少人会参与这个项目？在一个人项目中，你可以按照自己想要的方式做任何事情。在拥有3人以上的团队中，组件/模块将作为一个人独立工作的自然容器。因此，表单项目可能不依赖于类层次结构的外观 - 而是最多将要处理的代码位置应该彼此充分隔离。如果需要，类层次结构应该适应：你应该避免一个人在基类上工作的情况 - 另一个人在其后代上工作。在这种情况下，可以考虑聚合而不是继承。
答案 3 :(得分：0)
这个想法很简单。想象一下，您正在绘制类之间的依赖关系图，并选择一个最小化文件之间依赖关系的布局。
在文件级别也是如此，在文件夹级别也是如此，但是对于更大的代码单元。
您还应该知道编译器不能很好地优化文件之间的代码（问题是链接器）。因此，如果您有紧密耦合的类，将它们保存在同一个文件中对性能有好处。另一种解决方案，它可能只使它们成为标题类。
哪里有标题？如果您要提供库，则必须将它们放在通常的系统目录中。但是由于C ++头文件包含代码，因此将其保存为cpp文件的其他情况通常是最佳解决方案。它使hpp和cpp的编辑变得更加简单。