将自定义代码放在系统命名空间中答案

【问题标题】：Placing custom code in a System namespace将自定义代码放在系统命名空间中
【发布时间】：2011-02-07 05:23:48
【问题描述】：

是否有任何最佳实践表明不应将自定义代码放置在 System 命名空间中？ System 及其子代是否应该保留给 Microsoft 代码使用？

我问是因为我正在编写一个将在许多项目中使用的类库，我想通过将它放在 System.InteropServices 中来保持一致（因为它处理 P/Invoke）。

【问题讨论】：

标签： c# .net namespaces

【解决方案1】：

这不是一个好主意，因为它破坏了命名空间的主要好处之一：防止名称冲突。如果框架的较新版本在该命名空间中引入了同名类型怎么办？

这对System 命名空间尤其不利，因为它们是使用using 指令在许多其他代码段中导入的，并且在这些命名空间中引入自定义类型会污染具有意外标识符的其他源文件的命名范围。

要对您的自定义互操作相关类型进行分类，您可以创建一个新的命名空间，例如 MyProduct.InteropServices。

【讨论】：

我打算创建一个System.InteropServices 的子命名空间来避免这种情况，但我发现这可能仍然不是一个好主意。

【解决方案2】：

如果您在System.InteropServices 中放置一个新类，则每个具有using System.InteropServices; 子句的文件都会强制将您的类包含在范围内，这可能会使程序员感到困惑。由于程序员无法为此辩护，我认为这是一种不好的做法。

【讨论】：

【解决方案3】：

我不同意每个人。

我认为在有限的情况下（主要是扩展方法）将代码放在系统命名空间中是完全合理的。

这是我在电子邮件线程中的论点，我们在EPS 讨论了 System 命名空间中的扩展方法：

好的，这是我的观点：

我真的很喜欢最小化代码。这包括使用。
是的，ReSharper 选择扩展方法并为您添加使用，但有些人没有 ReSharper，此外，我更喜欢 Coderush，它实际上（据我所知）还没有选择扩展命名空间。
至少有两种不同类型的扩展方法；那些是我们应用程序的帮助方法 - 包括特定领域和应用程序的帮助方法，以及封装我们认为该语言应该开始使用的特性和语法的方法。

后者的一个很好的例子是能够执行"a {0} {1}".Format("b", "c") 或someListOfStrings.Join(", ") 而不必执行String.Join(someStringList.ToArray(), ", ")。其他更有争议的例子是IEnumerable<T>.ForEach 和IsNull() 扩展来代替笨拙的object.ReferenceEquals(null, someVar) 语法。

我的论点是，完全有理由将后一种分类 - 您的团队广泛同意应该使用该语言，但不是 - 在适当的命名空间（System、System.IO、System.Linq 等） .我们希望这些函数随处可用，就像我们希望 foreach 和 yield 关键字始终可见一样。如果它是特定于应用程序的，那么它应该放在自己的命名空间中。 90% 的时间特定于应用程序的帮助程序扩展不应该是扩展，甚至不是静态的。我从这个语句中排除了使用扩展方法为函数名提供别名的方法。

当调用包含系统范围扩展的程序集时，当然会遇到一些麻烦。假设我正在引用包含我的 void IEnumerable<T>.ForEach 方法的程序集，并且想要创建我自己的类似 ruby 的 R IEnumerable<T, R>.ForEach（它实际上只是一个 Select，但没关系）。这将是一个问题！为了缓解这个问题，我喜欢做的是将我的扩展类定义为内部的，以便它们只能在我的项目中使用。这很好地解决了这个问题。

【讨论】：