f4.*_*f4. 5 c++ namespaces code-organization
我目前正在尝试以更好的方式组织我的代码.
为此,我使用了名称空间,按组件对类进行分组,每个组都有一个已定义的角色和一些接口(实际上是抽象类).
我发现它非常好,特别是当我不得不重写整个组件时,我对其他组件几乎没有影响.(我相信使用一堆混合类和方法会更加困难)
然而,我并不是百分之百满意.特别是我想在接口,组件的公共面以及后面的实现之间做更好的分离.我认为组件本身的"接口"应该更清晰,我的意思是新来者应该很容易理解他必须实现什么接口,他可以使用什么接口以及实现的哪些部分.
很快,我将开始一个涉及多达5个开发人员的更大项目,我想在这一点上明白我的想法.
那你呢？你怎么做呢？你如何组织你的代码？
特别是我想在接口、组件的公共面及其背后的实现之间进行更好的分离。
我认为您正在寻找的是Facade模式：
外观是一个对象，它为更大的代码体（例如类库）提供简化的接口。——维基百科
如果您的类中存在复杂的交互，您可能还需要查看Mediator和Builder模式。
Pimpl惯用法（又名编译器防火墙）对于隐藏实现细节和减少构建时间也很有用。当我不需要多态性时，我更喜欢使用 Pimpl 而不是接口类 + 工厂。但要小心不要过度使用它。不要将 Pimpl 用于通常在堆栈上分配的轻量类型（例如 3D 点或复数）。将其用于更大、寿命更长的类，这些类依赖于您希望对用户隐藏的其他类/库。
在大型项目中，当简单的前向声明就可以时，不要在头文件中使用 #include 指令，这一点很重要。仅在绝对必要时才将#include 指令放入头文件中（最好将#include 放入实现文件中）。如果做得正确，正确的 #include 规则将显着减少编译时间。Pimpl 习惯用法可以帮助将 #includes 从头文件移动到相应的实现文件。
类/函数的连贯集合可以在其自己的命名空间中分组在一起，并放入源代码树的子目录中（子目录应与库命名空间具有相同的名称）。然后，您可以为该包创建静态库子项目/makefile，并将其与主应用程序链接。这就是我所认为的 UML 术语中的“包”。在理想的包中，类彼此紧密相关，但与包外的类松散相关。绘制包的依赖关系图有助于确保不存在循环依赖关系。