具有多层继承的大型C++项目的文件/文件夹布局

Question

我正处于一个相对较大的(10k+行)项目的规划阶段，该项目包含多个类(30+)和几级类继承(5+)。

在文件和文件夹结构方面，最好的(或最传统的)方法是什么？

1. 每堂课我要一份档案吗？每个继承分支应该有一个文件夹吗？
2. 我应该有一个包含我的头文件的'include‘文件夹，还是我的头文件应该和我的. .cpp/.c文件在同一个文件夹中？
3. 我计划定期添加更多的类(向继承树添加更多的级别)。在树的最低层，实现可能相对不相关，但仍然覆盖相同的虚拟函数。这些不相关的实现应该驻留在同一个文件夹中吗？

谢谢,

阿德维特

Answer 1

1)是。在大多数情况下，每个类只有一个文件是个好主意。除非您有一个非常简单的类，或者一个抽象接口集合，否则每个文件使用一个类。

2)试着把事情分开。通常，在这么大的项目中，您将有一些特定于某些部分的代码，而另一些则是许多部分所共有的代码。那些在使用上非常有限的，只需保持“本地”。其他，放在包括脏。

( 3)没有必要。通常最好是保持类(即文件)是密切相关的，紧密地放在一起；我会尝试将它们保持在一起，除非您在全局包含中具有类似于泛型接口的内容，并且在模块dir中具有特定的继承。

Answer 2

1)这看起来更像Java类型--但是如果类占用的行不超过4行，那么可能不是个好主意。但是如果以后您想要扩展一个已经存在的类，那么每个类都有一个文件是个好主意。

2)这是您的一个选择，如何安排您的.h文件和.cpp文件。但是，如果很多依赖关系都是针对单个类的，那么将相关的依赖放在一个地方似乎是合理的。

3)可能。但是，将基类/接口放在一个中心部分，并围绕它派生。

Answer 3

• 每堂课我要一份档案吗？每个继承分支应该有一个文件夹吗？

感谢代码索引器，我经常忘记代码在磁盘上的方式和位置。

每个班级的文件对我来说都是毫无意义的。特别是在C++中，我倾向于有很多小的实用程序类。

通常:组件是一个目录。所有组件都位于同一个根下。(这更令人遗憾，我不得不用make作为构建链。有了像SCons这样支持递归的更好的构建系统，这并不重要。)

我坚持对类进行分组的可重用性、充分性和内聚力(如布奇)的一般原则。我经常将代码放入共享/静态库中，以便于集成到构建链中，因此，对于将类分组到组件/目录中，我使用的原则非常类似于类中用于分组方法的原则。

• 我应该有一个包含我的头文件的'include‘文件夹，还是我的头文件应该和我的. .cpp/.c文件在同一个文件夹中？

我个人更喜欢在同一个目录中有源文件的标题。

值得注意的例外是定义组件公共接口的公共头。我将这些内容放入了include/compname/务虚会:那么很容易看出，我正在做/将要签入的更改将对其他组件产生影响。

显然，其他组件只允许包含来自$ROOT/compname/ include /compname/子目录的标题。(将compname/ dir包含/使其他文件中的include指令看起来类似于#include "compname/headername.h"，这有助于提高可读性并防止头名冲突。)

• 我计划定期添加更多的类(向继承树添加更多的级别)。在树的最低层，实现可能相对不相关，但仍然覆盖相同的虚拟函数。这些不相关的实现应该驻留在同一个文件夹中吗？

继承很少与文件的物理布局相关。

基类很少被修改，因为它们对业务逻辑几乎没有影响。顶级类是逻辑的核心所在，许多人将在很长一段时间内对其进行研究。因此，被许多组件重用的基本类应该有自己的组件。只是为了让他们离开视线。

这就引出了另一个重要的问题。有多少人要在这个项目上工作？在一个人的项目中，你可以用你想要的方式做任何你想做的事情。在有3+人员的团队中，组件/模块将充当一个人独立工作的自然容器。因此，表单项目采取的方式可能不取决于类层次结构的外观，而是要在大多数代码上工作的代码位置应该彼此充分隔离。如果需要的话，类层次结构应该能够适应这种情况:当一个人在基类上工作--另一个人在它的后代上工作时，您应该避免这种情况。在这种情况下，可以考虑聚合而不是继承。