问题标签 [namespaces]

我的 ClassA 类中的所有成员变量和成员函数都是静态的。

如果用户尝试（错误地）创建该类的对象，他会收到警告：“ClassA，从未引用局部变量”，因为所有函数都是静态的，因此永远不会引用该对象。因此，我想阻止用户尝试创建此类的对象。

创建一个私有默认（无变量）构造函数就足够了吗？或者我是否还必须创建私有复制构造函数和私有赋值运算符（以防止使用默认构造函数）？如果我也必须创建它们，也许只创建一些虚拟的纯虚函数会更好，这会阻止用户创建对象？

谢谢

无论如何，是否可以在 .net 2.0 应用程序中使用 .net 3.0 命名空间？我特别希望使用 System.Windows.Media.Media3D 命名空间。

编辑：我希望使用实际的程序集，而不仅仅是名称空间。我的措辞很糟糕。

我刚刚加入了一个新的 C++ 软件项目，我正在尝试了解该设计。该项目经常使用未命名的命名空间。例如，类定义文件中可能会出现这样的情况：

可能导致使用未命名命名空间的设计注意事项有哪些？有什么优点和缺点？

今天有人在 SO 上断言，你永远不应该在头文件中使用匿名命名空间。通常这是正确的，但我似乎记得曾经有人告诉我，其中一个标准库在头文件中使用匿名命名空间来执行某种初始化。

我没记错吗？有人可以填写详细信息吗？

考虑以下示例。它由两个头文件组成，声明了两个不同的命名空间：

第二个是

和一个单一的源文件，main.cpp：

这样它就不会编译（尝试过 GCC 和 MSVC）。错误是a1未声明命名空间（Windows 上的 C2653）。如果您以main.cpp这种方式更改包含顺序：

您会收到一条对称错误消息，即a2未声明命名空间。

有什么问题？

作为一名初学者/中级开发人员，我遇到了一个问题，因为我的项目变得越来越大，越来越抽象，因为我使用了更多的 OOP 原则，我在命名事物时遇到了问题。就像当我有多个项目或类库时，我不知道如何命名它们。我看到了从 xxx.Core 到 xxx.Main 的东西，甚至看到了 xxx.BLL 和 xxx.DAL。在浏览其他人时，我看到 xxx.Services 和 xxx.Data 用于他们的库和命名空间。

那么一旦解决了这个问题，我该怎么称呼 DTO？在那个领域我见过 xxx.DTO、xxx.Entities、xxx.Props。

在编码时命名库，方法，接口等有什么好的指导方针，以便越来越多的人在我之后接手项目时会理解事物。

我的团队正在开展一个转换项目，将一种产品（但有很多方面）从 VB6 转换为 .Net（我们有超过 300k LOC）。在我加入之前，我决定不管程序集的位置或文件夹结构如何，所有类/结构都将位于一个命名空间中：

.

他们甚至会更改自动生成的应用程序设置设计器代码、资源设计器代码等以强制统一。我如何说服他们使用命名空间是好的？命名空间的正确使用是什么，优缺点是什么？我想我很难理解为什么我的同事会经历如此多的麻烦来节省一些使用线。任何支持您的论点的外部、有信誉的参考将不胜感激。请帮忙！

我正在学习如何使用 Greasemonkey，并且想知道@namespace元数据 ID 的用途。

必须是网址吗？或者它可以是我计算机上的文件夹/目录吗？

它甚至需要填写吗？

我正在考虑将我用 C# 编写的类库之一作为开源发布。在此之前，我正在尝试进行一些重构，以满足公众的需求:)

我想知道最好使用的命名空间模式是什么？基本上，我看到以下选项：

• namespace MyTool：这对我来说看起来并不像是有组织的。我的意思是，（几乎）.NET Framework 中的所有命名空间都以 System 为前缀，所以我想这并不是真正的标准方法。
• namespace MyOrganization.MyTool：问题在于根本没有“MyOrganization”。是闲暇时写的。
• namespace MyName.MyTool：我更喜欢更谦虚的东西。我的意思是，我真的不想在命名空间中有我的名字。

现在 Stackoverflow 上已经有几个相关的问题了，比如this和this，但没有一个能真正回答我的问题。

有什么建议么？

我记得读过一次（我相信这本书是 .NET Framework 设计指南），当您设计框架或类库时，您应该注意如何在命名空间中安排类。具体来说，父命名空间中的类不应该知道子命名空间中的类。相反，子命名空间中的类知道它们上方命名空间中的类是完全可以的。

例如，System命名空间中的类对System.Data.SqlClient命名空间中的类一无所知。但是，System.Data.SqlClient中的类知道System和System.Data中的类。

现在，从表面上看，这是一个非常简单的想法。但在某些情况下，这并不像您想象的那么容易实现。类在本质上是相互耦合的。例如：

• 商务舱
• 数据实体类
• 将数据实体类映射到业务对象类的类
• 将数据实体序列化到数据库和从数据库序列化的类

当然，您可以将它们分成单独的离散类，从而清楚地隔离数据和功能；那不是我的问题。我的问题是如何将它们正确排列到遵循命名空间最佳实践的命名空间中。

这对我来说总是有点模糊。我从未见过它被明确解决，而且我见过的大多数示例只是将数据对象放在根命名空间 (MyProject.DataObjects) 或类似的东西之外。好像没有人真正确定，所以我们只是不谈论它。

我可以看到，在 .NET Framework 本身中，类一直跨越命名空间边界来访问它们需要的功能。类经常从System.Collections、System.Collections.Generic、System.Runtime、System.Configuration、System.Reflection等访问功能。

就好像有一条潜规则规定，当涉及到命名空间时，“你对自己的孩子一无所知，但你可以知道关于你的祖父母、阿姨、叔叔、侄女的孩子的一切，侄子和堂兄弟。” 这条准则对我来说似乎违反直觉且毫无意义。它似乎使命名空间设计复杂化。

所以这是问题

您如何在自己的大型应用程序中设计命名空间？您真的关心保留命名空间边界吗？如果是这样，您如何解决类明确相关的问题（尽管已经尽可能多地解耦）？

我对您的经历以及您对此的意见非常感兴趣。它已经困扰我一段时间了。如果您可以为包含业务对象、数据实体等的 3 层应用程序提供命名空间安排的示例，那就太好了。我真的很想看看你们是如何获得命名空间模型的，以及为什么。

首先十分感谢！