将新类添加到框架命名空间是一种好习惯吗？答案

【问题标题】：Is it good practice to add new classes to framework namespaces?将新类添加到框架命名空间是一种好习惯吗？
【发布时间】：2011-05-19 07:27:34
【问题描述】：

很久以前，我记得读过 Microsoft 强烈建议不要将自己的类添加到框架命名空间。我一直在寻找它没有成功。

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

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

【问题讨论】：

常识对你来说还不够好吗？这些名称是一个很好的指标：System 和 Microsoft 显然不属于您或您的公司。您是否只是在寻找正式的东西来说服同事？
后者。有大量关于将东西扔进 System.Collections.Generic 或 System.Linq 的示例代码（大概是为了让懒惰的消费者不必添加额外的“使用”）。我正在努力打破对货物的狂热。
我必须承认，我从未见过将东西扔进System.Collections.Generic的示例代码。也许它发生在 LINQ 上；我仍然有点回避整个竞技场。我不知道这是一种货物崇拜。
我看到的第一个例子是PagedList：blog.wekeroad.com/2007/12/10/aspnet-mvc-pagedlistt（奇怪的是，这里的作者在System.Web.Mvc中有它，由于各种原因，这肯定是错误的地方！），或者是的，尤其是 System.Linq：coderenaissance.com/2011/02/extending-linq-to-objects.html、blog.robvolk.com/2009/05/…、brandonatkinson.blogspot.com、geekswithblogs.net/bdiaz/Default.aspx - 我认为这很常见，值得讨论。

标签： .net namespaces naming-conventions design-guidelines

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

here:

命名约定

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

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

"Design Guidelines for Developing Class Libraries" 也有类似的规则：

命名空间名称的一般格式如下：
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
例如，Microsoft.WindowsMobile.DirectX。

请在命名空间名称前加上公司名称，以防止来自不同公司的命名空间具有相同的名称和前缀。

不要在命名空间名称的第二层使用稳定的、独立于版本的产品名称。

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

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

不要使用 Pascal 大小写，并用句点分隔命名空间组件（例如，Microsoft.Office.PowerPoint）。如果您的品牌使用非传统的大小写，您应该遵循您的品牌定义的大小写，即使它不同于正常的命名空间大小写。

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

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

还有：

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

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

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

当然，你can do it if you really want to。

【讨论】：

【解决方案3】：

建议使用Company.Product.Component 作为命名空间。我认为这可能包括不在您自己的产品中使用框架命名空间。见MSDN: Names of Namespaces (Design Guidelines for Developing Class Libraries )。

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

希望对您有所帮助。

干杯，马蒂亚斯

【讨论】：