c++命名空间使用和命名规则答案

【问题标题】：c++ namespace usage and naming rulesc++命名空间使用和命名规则
【发布时间】：2009-03-02 18:13:13
【问题描述】：

在该项目中，我们正试图就命名空间的使用达成一致。我们决定第一层是“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++ 中，在命名空间上划分模块的最佳做法是什么？

【问题讨论】：

标签： c++ namespaces

【解决方案1】：

命名空间的用途：

命名空间仅用于建立上下文，因此您不会遇到命名冲突。

一般规则：

不需要指定过多的上下文，并且会带来比其价值更多的不便。

所以你想用你最好的判断，但仍然遵循这两条规则：

使用命名空间时不要太笼统
使用命名空间时不要太具体

我不会对如何使用命名空间名称如此严格，而是简单地使用基于相关代码组的命名空间。

为什么过于笼统的命名空间没有帮助：

以产品名称开头划分命名空间的问题在于，您通常会有一个代码组件，或者多个产品共有的一些基础库。

您也不会在 Product1 中使用 Product2 命名空间，因此明确指定它是没有意义的。如果您将 Product2 的文件包含在 Product1 中，那么这种命名转换还有用吗？

为什么过于具体的命名空间没有帮助：

当您拥有过于具体的命名空间时，这些不同的命名空间之间的界限开始变得模糊。您开始来回使用彼此内部的命名空间。这时候最好把通用代码一起泛化到同一个命名空间下。

具有所有静态与模板的类：

"我们为什么要创建inner not 私有类而不是命名空间？为什么我们要创建所有的类方法是静态的”

一些区别：

可以使用 using 关键字来暗示命名空间
命名空间可以是别名，类是类型并且可以定义类型
可以添加命名空间；您可以随时为其添加功能并直接添加到其中
如果不创建新的派生类，就无法添加类
命名空间可以有前向声明
通过类，您可以拥有私有成员和受保护成员
类可以与模板一起使用

具体怎么划分：

"项目包含 1Gb 的源代码。那么，最佳实践是什么在命名空间中划分模块 c++？”

在没有确切源代码的情况下准确地说出如何划分代码太主观了。根据模块进行划分虽然听起来合乎逻辑，但不是整个产品。

【讨论】：

好的，如果我添加然后 domainObject::Settings 和其他人将添加 DomainObjectValidator 等等 - 会有一个混搭。
为什么要将其他产品的包含文件包含到您的产品中？
您可能会遇到此问题的事实意味着您无论如何都不应该用产品名称标记它们，因为这意味着您在其命名空间不适合的产品中使用此模块.
输入产品名称是基本代码约定。就像将 ProductPrefix 放在所有类和函数中一样。
如果产品名称发生变化，我不愿意处理该代码。最好根据代码的作用来命名。

【解决方案2】：

在我看来，您正在尝试将命名空间用作设计工具。它们不是为此而设计的，它们旨在防止名称冲突。如果没有冲突，则不需要命名空间。

【讨论】：

是这样吗？那么为什么boost会引入这么多不同的关卡呢？它可以只使用长名称。像 boostThreadJoinAll。命名空间也是浏览的工具。向我展示与域相关的所有内容。
Boost 使用它们来防止名称冲突，就像我说的那样。

【解决方案3】：

这都是主观的，但我会犹豫是否要深入超过 3 个级别。在某些时候它变得太笨拙了。所以除非你的代码库非常非常大，否则我会保持它很浅。

我们将代码划分为子系统，并为每个子系统设置一个命名空间。如果实用程序确实可以跨子系统重用，它们将进入它们自己的命名空间。

【讨论】：

所以没有不同的“域区域”？我的意思是所有业务类都在同一个命名空间中？
好吧，如果没有看到您的架构，很难理解您的意思，但是对我来说，每个域区域的命名空间听起来是个好主意。整个想法是在混合代码的不同区域时防止名称冲突。

【解决方案4】：

我根据其用途划分命名空间：

我有一个单独的命名空间，我在其中定义了所有接口（纯虚拟类）。

我有一个单独的命名空间，我在其中定义了我的库类（如 db 库、处理库）。

我有一个单独的命名空间，其中有我的核心业务（业务逻辑）对象（如 purchase_order 等）。

我想，它是以某种方式定义它，这在未来不会变得难以处理。因此，您可以检查当前设计中的困难。

如果你认为他们很好，你应该去。

【讨论】：