我可以理解一级名称空间的用法。但是3个级别的名称空间。看起来很疯狂。有实际用途吗？还是只是一个误解？

解决方案

大型代码库将需要它。以boost为例。我认为没有人会称助推代码为"疯狂"。

如果我们考虑一个事实，即在层次结构的任何一个级别上，人们只能大致理解10个项目的数量，那么两个级别只会给我们100个最大值。一个足够大的项目将需要更多，因此很容易最终达到3个层次。

显然这是一个见解。但这实际上归结为组织。例如，我有一个项目，该项目的插件API具有如下所示的函数/对象：

plugins::v1::function

推出2.0版本后，它们将被放入v2子命名空间中。我计划仅弃用但永远不要删除v1成员，将来应该很好地支持向后兼容。这只是"理智"用法的一个例子。我想有些人会有所不同，但是就像我说的那样，这只是见仁见智。

我在公司yyy上从事XXX应用程序的工作，并且正在编写GUI子系统。因此，我使用yyy :: xxx :: gui作为我的命名空间。

分层名称空间确实有其用处，因为它们允许逐渐更完善的定义。当然，单个提供程序可能会产生两个具有相同名称的类。通常，第一级由公司名称占据，第二级指定产品，第三级(可能还有更多)提供域。

命名空间隔离还有其他用途。一种流行的情况是将工厂模式的基类放置在其自己的名称空间中，然后由提供者将派生工厂放置在其自己的名称空间中。例如。 System.Data，System.Data.SqlClient和System.Data.OleDbClient。

这取决于需求和编程风格。但是，namespace的好处之一是可以帮助对命名空间进行分区(因此命名)。使用单个名称空间，随着项目的规模和复杂性的增加，名称冲突的可能性也会增加。

如果我们要编写要共享或者重用的代码，这将变得更加重要。

当我们需要多个级别时，我们可以轻松找到自己的处境。例如，公司有一个巨大的名称空间，用于将其所有代码与第三方代码分开，并且我们正在编写要放入其自己的名称空间的库。通常，只要我们有一个非常大而复杂的系统(将其按层次划分)，就可以使用多个命名空间级别。

我同意申请。大多数人(根据我的经验)使用多个级别的名称空间来自Java或者.NET背景，其噪音要小得多。我发现良好的类前缀可以代替多层名称空间。

但是我已经看到在boost(和其他库)中很好地使用了多个名称空间级别。一切都在boost命名空间中，但允许(鼓励？)库位于其自己的命名空间中。例如boost :: this_thread命名空间。它允许...

boost::this_thread::get_id()
boost::this_thread::interruption_requested()

" this_thread"只是自由函数集合的名称空间。我们可以使用类和静态函数(即Java定义自由函数的方法)执行相同的操作，但是当语言具有自然的用法时，为什么会做一些不自然的操作呢？

只需查看.Net基类库，便可以充分利用命名空间层次结构。它在几个地方深入到四个或者五个级别，但大多数情况下只有两个或者三个级别，并且该组织非常擅长查找内容。

代码库越大，对分层名称空间的需求就越大。随着项目变得越来越大，我们会发现需要以使其更容易找到东西的方式进行突破。

例如，我们当前使用2级层次结构。但是，我们现在讨论的一些较大部分将其分为3个级别。