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

发布于 2024-11-08 12:33:47 字数 163 浏览 0 评论 0原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

楠木可依 2024-11-15 12:33:47

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

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

回复收藏 0 原文

星軌x 2024-11-15 12:33:47

此处似乎表述得很清楚：

命名约定
.NET Framework 类型使用表示层次结构的点语法命名方案。该技术将相关类型分组到命名空间中，以便更轻松地搜索和引用它们。全名的第一部分（直到最右边的点）是命名空间名称。名称的最后一部分是类型名称。例如，System.Collections.ArrayList 表示 ArrayList 类型，它属于 System.Collections 命名空间。 System.Collections 中的类型可用于操作对象集合。
此命名方案使扩展 .NET Framework 的库开发人员可以轻松创建类型的分层组，并以一致、信息丰富的方式命名它们。它还允许通过全名（即命名空间和类型名称）明确标识类型，从而防止类型名称冲突。预计库开发人员在为其命名空间创建名称时将使用以下指南：
公司名称.技术名称
例如，命名空间 Microsoft.Word 就符合此准则。

“开发类库的设计指南”也有类似的规则：

命名空间名称的一般格式如下：
<代码><公司>.(<产品>|<技术>)[.<功能>][.<子命名空间>]
例如，Microsoft.WindowsMobile.DirectX。
务必在命名空间名称前加上公司名称前缀，以防止不同公司的命名空间具有相同的名称和前缀。
务必在命名空间名称的第二级使用稳定的、与版本无关的产品名称。
请勿使用组织层次结构作为命名空间层次结构中名称的基础，因为公司内的组名称往往是短暂的。
命名空间名称是一个长期存在且不变的标识符。随着组织的发展，更改不应使命名空间名称过时。
请使用 Pascal 大小写，并用句点分隔命名空间组件（例如，Microsoft.Office.PowerPoint）。如果您的品牌采用非传统大小写，您应该遵循您的品牌定义的大小写，即使它偏离正常的命名空间大小写。
考虑在适当的情况下使用复数命名空间名称。例如，使用System.Collections 而不是System.Collection。然而，品牌名称和缩写词是这条规则的例外。例如，使用 System.IO 而不是 System.IOs。
请勿对命名空间和该命名空间中的类型使用相同的名称。例如，不要使用 Debug 作为命名空间名称，并在同一命名空间中提供名为 Debug 的类。一些编译器要求此类类型是完全限定的。

和：

核心命名空间是 System.* 命名空间（不包括应用程序和基础结构命名空间）。 System 和 System.Text 是核心命名空间的示例。您应该尽一切努力避免与核心命名空间中的类型发生名称冲突。
请勿给出与核心命名空间中的任何类型冲突的类型名称。
例如，请勿使用 Directory 作为类型名称，因为这会与 Directory 类型冲突。

但是，当然，您 如果你真的想的话可以做到。

It seems pretty clearly stated here:

Naming Conventions
.NET Framework types use a dot syntax naming scheme that connotes a hierarchy. This technique groups related types into namespaces so they can be searched and referenced more easily. The first part of the full name — up to the rightmost dot — is the namespace name. The last part of the name is the type name. For example, System.Collections.ArrayList represents the ArrayList type, which belongs to the System.Collections namespace. The types in System.Collections can be used to manipulate collections of objects.
This naming scheme makes it easy for library developers extending the .NET Framework to create hierarchical groups of types and name them in a consistent, informative manner. It also allows types to be unambiguously identified by their full name (that is, by their namespace and type name), which prevents type name collisions. It is expected that library developers will use the following guideline when creating names for their namespaces:
CompanyName.TechnologyName
For example, the namespace Microsoft.Word conforms to this guideline.

And the "Design Guidelines for Developing Class Libraries" carry a similar rule:

The general format for a namespace name is as follows:
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
For example, Microsoft.WindowsMobile.DirectX.
Do prefix namespace names with a company name to prevent namespaces from different companies from having the same name and prefix.
Do use a stable, version-independent product name at the second level of a namespace name.
Do not use organizational hierarchies as the basis for names in namespace hierarchies, because group names within corporations tend to be short-lived.
The namespace name is a long-lived and unchanging identifier. As organizations evolve, changes should not make the namespace name obsolete.
Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint). If your brand employs nontraditional casing, you should follow the casing defined by your brand, even if it deviates from normal namespace casing.
Consider using plural namespace names where appropriate. For example, use System.Collections instead of System.Collection. Brand names and acronyms are exceptions to this rule, however. For example, use System.IO instead of System.IOs.
Do not use the same name for a namespace and a type in that namespace. For example, do not use Debug for a namespace name and also provide a class named Debug in the same namespace. Several compilers require such types to be fully qualified.

And:

The core namespaces are the System.* namespaces (excluding the application and infrastructure namespaces). System and System.Text are examples of core namespaces. You should make every effort to avoid name collisions with types in the core namespaces.
Do not give types names that would conflict with any type in the core namespaces.
For example, do not use Directory as a type name because this would conflict with the Directory type.

But, of course, you can do it if you really want to.

回复收藏 0 原文