我目前正在尝试以更好的方式组织我的代码。
为此，我使用了命名空间，按组件对类进行分组，每个组件都有一个定义的角色和一些接口(interface)(实际上是抽象类)。
我发现它非常好，尤其是当我不得不重写整个组件时，我这样做几乎不会对其他组件产生影响。 (我相信一堆混合类和方法会更加困难)
但我并不是 100% 满意它。特别是我想在接口(interface)、组件的公共(public)面孔和它们背后的实现之间做一个更好的分离。 我认为组件本身的“接口(interface)”应该更清晰，我的意思是新手应该很容易理解他必须实现哪些接口(interface)，他可以使用哪些接口(interface)以及实现的哪些部分。
很快我将开始一个更大的项目，最多涉及 5 名开发人员，我想清楚这一点。
那你呢？你怎么做呢？你如何组织你的代码？
最佳答案
Especially I'd like to do a better separation between interfaces, the public face of the components, and their implementations in behind.
我认为您正在寻找的是 Facade图案:
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. -- Wikipedia
您可能还想查看 Mediator和 Builder如果您的类(class)中有复杂的交互，请使用模式。
Pimpl idiom(又名编译器防火墙)对于隐藏实现细节和减少构建时间也很有用。当我不需要多态性时，我更喜欢使用 Pimpl 而不是接口(interface)类 + 工厂。不过要小心不要过度使用它。不要将 Pimpl 用于通常在堆栈上分配的轻量级类型(如 3D 点或复数)。将它用于更大、生命周期更长的类，这些类依赖于您希望对用户隐藏的其他类/库。
在大型项目中，重要的是不要在头文件中使用#include 指令，而只需简单的前向声明即可。只有在绝对必要时才将#include 指令放在头文件中(最好将#includes 放在实现文件中)。如果做得对，适当的#include 纪律将显着减少编译时间。 Pimpl 习惯用法有助于将#includes 从头文件移动到它们相应的实现文件。
类/函数的连贯集合可以在它自己的命名空间中组合在一起，并放在源代码树的子目录中(子目录应与库命名空间同名)。然后，您可以为该包创建一个静态库子项目/makefile，并将其链接到您的主应用程序。这就是我认为的 UML 术语中的“包”。在一个理想的包中，类彼此紧密相关，但与包外的类松散相关。绘制包的依赖关系图有助于确保不存在循环依赖关系。
关于c++ - C++项目中如何更好的组织代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2112247/