C++ 为接口和实现使用单独的名称空间是否值得？

为接口和实现使用单独的名称空间是否值得

Stroustrup在他的C++书（第四版）中的建议是，我们应该使用单独的命名空间。 用于接口和实现。更有经验的人能说些什么吗 在这件事上？我的意思是这听起来不错，但它真的实用吗？它在中国有意义吗

---

真实世界项目？

名称空间告诉您定义属于谁。当然，接口属于与实现不同的组是有意义的；这就是接口的全部要点，关注点的分离。

对于那些需要大量实现的代码（比如Boost中的一些元编程怪物），一眼就能看出哪些代码是可以直接使用的，哪些代码可以安全地忽略，这是非常有用的。库的detail命名空间中的代码被视为“内部”代码，因此当您在堆栈跟踪中看到detail符号时，无需花时间查找文档

我不会说它有很大的好处，在一般情况下肯定不是这样，但既然它不会造成任何伤害，你最好保持东西整洁和隔离

这在现实世界的项目中有意义吗

是的，例如在boost中，它被广泛使用。比如说。只要我看到

名称空间细节

，我马上就知道我没有太多的时间去查看代码段，除非有错误消息告诉我这样做（即使这样，也很可能是我的错）

强制性设计的真实世界启发示例 我想你知道如何驾驶汽车。有许多接口：方向盘、油门/刹车/离合器踏板、显示器等。您对使用这些接口感兴趣，毕竟，这就是您使用汽车的方式：

namespace the_company{
  struct wheel{
    void turnLeft(deg);
    void turnRight(deg) { turnLeft(-deg); }
  };
  struct pedal{
    void tap();  
    void press_completely_till_something_happens(); 
      //!< might deadlock if using break and car isn't moving
  };
  struct display{
    so_many_colors lookat();
  };
}

我们对

汽车有什么期望？我们可以预期，我们可以使用汽车的车轮或踏板，它将工作：

car myCar;
myCar.getGasPedal().press_completely_till_something_happens();

// OH GOD; WHAT HAVE I DONE!?

myCar.getWheel().turnLeft(360);

myCar.getBreakPedal().press_completely_till_something_happens();
// Shew. That was close.

我们完全可以使用
汽车
。顺便说一句，我们没有把
轮子
放进
汽车
，因为我们公司可能会生产其他使用轮子的东西，比如船只、卡车、人造飞机、阀门和其他非车辆的东西，而
显示器
可能会被更多不同的东西使用（电话、显示器、电视，你可以随便说）

然而，为了实际运行汽车，它必须有一个发动机。由于发动机是一些相当复杂的机械，我们将其隐藏在发动机罩下：

namespace the_company{
  namespace hood{
    struct engine{
      // heavily optimized code
      // not so nice interface anymore
      // maybe not even documentated
      ...
    };
  }
}

引擎
是个怪兽，它具有可扩展性，可用于任何车辆或重型机械，贵公司在优化方面投入了大量精力。现在，每当车主的发动机出现问题时，他只需查看发动机罩，检查出了什么问题

但事实上，它隐藏在某些东西后面，从一开始就告诉用户，他应该知道自己将要做什么。如果他不理解金属/代码，他应该向他的服务维护/支持部门寻求帮助

此外，
引擎
可能会发生变化，甚至被完全移除，因为我们公司发明了
fusion_引擎
，这可以带来更好的利润

这就是
名称空间细节对我来说的意义：复杂的细节，可能会改变，甚至可能只对原始的维护人员有意义。但那很好。它不是界面的一部分。< / P>如果它没有意义，他就不会提到它。@ RobertJacobs有Stroustrup的其他C++书籍第四版吗？！我只是觉得你应该把整个标题放在问题的某个地方。“它在现实世界的项目中有意义吗？”是的，例如在
boost
中，它被广泛使用。比如说。一旦我看到
名称空间详细信息
，我马上知道我没有太多的时间来研究该代码段，除非有错误消息告诉我这样做。如果可以的话，这是一个很好的问题，我建议OP将此问题保持开放一天左右，以便获得所有可能的答案，并真正选择最好的答案。我希望您不要着急：基本上，我们可以将名称空间看作一个类。有时，我们希望将某些部分设置为私有（对于实现者）而将其他部分设置为公共（对于用户）。因为我们不能用名称空间实现这一点，所以我们只能创建单独的名称空间。因此，我想这就是这个建议的全部内容。@user311311311311从类的角度思考名称空间只会混淆问题。虽然这是一个非常有创意的例子，但它是OO甚至名称空间使用的一个非常糟糕的例子，我认为它并没有真正的帮助：P@LightnessRacesinOrbit当前位置我几乎不记得写过这篇文章。一定是在醒来和第一口咖啡之间。哈哈。不过，值得保留：）
namespace the_company{
  namespace hood{
    struct engine{
      // heavily optimized code
      // not so nice interface anymore
      // maybe not even documentated
      ...
    };
  }
}