创建许多头文件，只是#include 许多文件（就像一个集线器文件）

Question

It is a bad idea to stuff a lot of #include into 1 file.

我的情况有点不同 - 我要创建多个集线器文件仅包含一些 #include:-

PhysicCommonHub.h :-

#include "PhysicCompound.h"    //~ 100 lines
#include "PhysicConstraint.h"  //~ 100 lines
#include "PhysicDummy.h"       //~ 100 lines
#include "PhysicUtil.h"        //~ 100 lines
//In real case, I include around 5 files.

GraphicCommonHub.h :-

#include "GraphicMesh.h"           //~ 100 lines
#include "GraphicLightSource.h"    //~ 100 lines
#include "GraphicUtil.h"           //~ 100 lines

我的情况（和动机）是：-

每当我想包含一个文件时，大约有 30% 的人还希望在同一个 hub 中包含另一个文件。
例如，如果包含 PhysicCompound.h，则有 30% 的更改我还必须包含 PhysicConstraint.h，30% 用于 PhysicDummy.h，等等。

因此，如果我要包含 PhysicCompound.h，我将只包含 PhysicCommonHub.h。

优点：-

代码更简洁（缩短）
方便，生产力提高（一点多一点）

缺点：-

可维护性降低（有点？）
编译时间增加了一点

问题

值得吗？这是坏主意还是坏做法？只是 "depend" 吗？
现实中有这样的门槛（百分比）吗？
更具体地说，创建一些 hubs 文件是否是一个好的决定？
如果只是为了前向声明使用集线器技术呢？
更具体地说，是否有任何情况表明这是一个好的决定？

PhysicForwardHub.h :-

class PhysicCompound;
class PhysicConstraint;
class PhysicDummy;
class PhysicUtil;

从近距离投票来看，我将假设它 "depends"，即两个问题的答案都是 "yes"。 (?)

Answer 1

我不会仅仅将您的方法描述为 "bad practice"。我会把它描述为糟糕的做法。

实际上，您的每个 "hub headers" 都会产生与您链接到的那个问题中描述的相同的效果。

将这样的 header 分开（所以有多个 "hub header"，就像你描述的那样）可能会减轻与包含很多的单个 header 相关的一些影响其他 header 个。但是，这不是对您的方法的建议。这表明单个全局 header 有多糟糕 - 你的方法只是没那么糟糕，而不是提供一些 "goodness" 替代方案。

虽然您将对可维护性或编译的影响描述为 "a bit"（即暗示它们不重要），但实际情况是影响相当大。这些影响在小项目中可能不明显，但在大项目中却很可怕。影响包括构建时间按数量级增加，以及生产力显着下降（包括开发人员绞尽脑汁等待新代码编译，以便他们可以对其进行测试）。

仅将此技术用于前向声明不会有太大收获。总会有代码需要完整的类型定义，而不仅仅是前向声明。并且将 "hub header" 仅用于前向声明实际上只是楔子的薄边 - 毕竟，说 "okay, I've done it for forward declarations .... now for the headers with the class definitions ....".

只是一小步

实际上，虽然决定每个编译单元需要什么 header 需要一些思考，但这种努力通常只占实际实现新代码所花费时间的一小部分。因此，您所描述的是一种虚假的经济 - 减少思考代码的工作量，从而影响整个项目的各种生产力指标。

创建许多头文件，只是#include 许多文件（就像一个集线器文件）

Create many header files that just #include many files (act like a hub file)

c++

include

header-files

我的情况（和动机）是：-

问题