2

很久以前，我记得读过微软的一个非常强烈的建议，反对将你自己的类添加到框架命名空间中。我一直在寻找它没有成功。

我记得的主要原因是该框架的后续版本可能会出现类名冲突。

还有其他原因吗？你会推荐将自己的类添加到框架命名空间吗？是否有任何关于此事的官方指导？

4

3 回答 3

4

当您尝试存根不再/尚未存在的东西时，您希望在不属于您的命名空间中拥有一个类的唯一情况是在您不想更改的代码库中使用。

例如，我编写了一个 HashSet 实现并将其放置在 System.Collections.Generic 命名空间中，用于在 .NET 3.5 处于测试阶段时针对 .NET 2.0 的应用程序。我知道我们将升级到 .NET 3.5 并在时机成熟时删除这个类。

于 2011-05-19T07:49:03.487 回答
3

这里似乎很清楚地说明了：

命名约定

.NET Framework 类型使用表示层次结构的点语法命名方案。该技术将相关类型分组到命名空间中，以便更轻松地搜索和引用它们。全名的第一部分——直到最右边的点——是命名空间名称。名称的最后一部分是类型名称。例如，System.Collections.ArrayList表示ArrayList属于 System.Collections 命名空间的类型。中的类型System.Collections可用于操作对象的集合。

这种命名方案使扩展 .NET Framework 的库开发人员可以轻松地创建层次结构的类型组并以一致、信息丰富的方式对其进行命名。它还允许通过它们的全名（即通过它们的命名空间和类型名称）明确标识类型，从而防止类型名称冲突。预计库开发人员在为其命名空间创建名称时将使用以下准则：

CompanyName.TechnologyName

例如，命名空间Microsoft.Word符合此准则。

而《类库开发设计指南》也有类似的规定：

命名空间名称的一般格式如下：

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

例如，Microsoft.WindowsMo​​bile.DirectX。

使用公司名称为命名空间名称添加前缀，以防止来自不同公司的命名空间具有相同的名称和前缀。

请在命名空间名称的第二级使用稳定的、与版本无关的产品名称。

不要使用组织层次结构作为命名空间层次结构中名称的基础，因为公司内的组名称往往是短暂的。

命名空间名称是一个长期存在且不变的标识符。随着组织的发展，更改不应使命名空间名称过时。

请务必使用 Pascal 大小写，并使用句点分隔命名空间组件（例如，Microsoft.Office.PowerPoint）。如果你的品牌使用非传统的大小写，你应该遵循你的品牌定义的大小写，即使它偏离了正常的命名空间大小写。

考虑在适当的情况下使用复数命名空间名称。例如，使用System.Collections代替System.Collection. 但是，品牌名称和首字母缩略词是此规则的例外。例如，使用System.IO代替System.IOs.

不要对命名空间和该命名空间中的类型使用相同的名称。例如，不要Debug用于命名空间名称，并且还提供Debug在同一命名空间中命名的类。一些编译器要求这些类型是完全限定的。

和：

核心命名空间是 System.* 命名空间（不包括应用程序和基础设施命名空间）。System并且System.Text是核心命名空间的示例。您应该尽一切努力避免与核心命名空间中的类型发生名称冲突。

不要给出与核心命名空间中的任何类型冲突的类型名称。

例如，不要Directory用作类型名称，因为这会与Directory类型冲突。

但是，当然，如果你真的想这样做，你也可以这样做。

于 2011-05-19T07:41:53.140 回答
2

有一个建议Company.Product.Component用作命名空间。我认为这可能包括不在您自己的产品中使用框架命名空间。请参阅MSDN：名称空间的名称（开发类库的设计指南）。

就我个人而言，我永远不会System为我自己的类使用命名空间，就像它们不属于 .NET 框架一样。我都不会java.lang在Java中使用。不过，这只是我个人的看法。

希望有帮助。

干杯，马蒂亚斯

于 2011-05-19T07:33:54.377 回答