在项目中，我们正试图就名称空间使用达成一致。 我们决定第一级是“productName”，第二级是“moduleName”。
productName::moduleName
现在，如果模块是一种实用程序模块，则添加第三个命名空间没有问题。例如，添加“str”：productName :: utilityModuleName :: str - 来划分所有“字符串”相关内容的空间。
如果模块是主要业务模块，我们有很多机会，几乎没有协议。
例如
class productName::mainModuleName::DomainObject
和
class productName::mainModuleName::DomainObjectSomethingElseViewForExample
可以在
namespace productName::mainModuleName::domainObject
class Data
class ViewForExample
我们为什么要创建内部非私有类而不是名称空间？ 我们为什么要创建所有方法都是静态的类（除非这个类是模板参数的情况除外）？
项目包含1Gb的源代码。 那么，在c ++中划分命名空间模块的最佳实践是什么？
答案 0 :(得分：39)
用于命名空间的名称空间：
命名空间仅用于建立上下文，因此您没有命名配置。
一般规则：
不需要指定太多的上下文，并且会带来更多的不便。
所以你想要用最好的判断，但仍然遵循以下两条规则：
对于如何使用命名空间名称，以及仅使用基于相关代码组的命名空间，我不会那么严格。
为什么过于笼统的命名空间无效：
将命名空间从产品名称开始划分的问题在于，您通常会拥有一个代码组件，或者一些多个产品通用的基本库。
您也不会在Product1中使用Product2名称空间，因此明确指定它是没有意义的。如果您在Product1中包含Product2的文件，那么这个命名转换是否仍然有用？
为什么过于具体的命名空间没有帮助：
如果命名空间太具体，则这些不同命名空间之间的界限开始模糊。您开始来回使用彼此内部的名称空间。此时，最好在同一名称空间下将公共代码一起概括。
包含所有静态vs模板的类：
“我们为什么要创造内心而不是 私有类而不是名称空间？ 我们为什么要创建所有类 方法是静态的“
一些差异：
using关键字究竟如何划分：
“项目由1Gb源代码组成 码。那么，最佳实践是什么？ 在命名空间中划分模块 C ++？“
如果没有确切的源代码，确切地说如何划分代码是太主观了。基于模块划分虽然听起来合乎逻辑，但不是整个产品。
答案 1 :(得分：5)
这一切都是主观的，但我会毫不犹豫地超过3级。它在某些方面变得太笨重了。因此，除非你的代码库非常非常大，否则我会保持它非常浅。
我们将代码划分为子系统，并为每个子系统设置命名空间。如果实际上它们可以跨子系统重用，那么实用程序将进入它们自己的命名空间。
答案 2 :(得分：3)
在我看来，您正在尝试使用名称空间作为设计工具。它们并非旨在用于此目的，它们旨在防止名称冲突。如果没有冲突，则不需要命名空间。
答案 3 :(得分：0)
我根据其用法划分名称空间：
我有一个单独的命名空间，我已经定义了所有的接口（纯虚拟类）。
我有一个单独的命名空间，我已经定义了我的库类（比如db库，处理库）。
我有一个单独的命名空间，我有我的核心业务（业务逻辑）对象（如purchase_order等）。
我想，它是关于以某种方式定义它，这在将来变得难以处理。因此，您可以检查当前设计所面临的困难。
如果你认为他们没事，你就应该坚持下去。