扩展 FCL 的 System 命名空间真的是个坏习惯吗？答案

【问题标题】：Expanding the FCL's System namespace truly a bad practice?扩展 FCL 的 System 命名空间真的是个坏习惯吗？
【发布时间】：2011-02-16 01:33:59
【问题描述】：

common knowledge (and convention) 命名空间用于唯一标识代码并防止名称冲突，这就是为什么您应该始终将自己的代码尽可能放在唯一的命名空间中。

但是，...

命名空间还用于将逻辑相关的类组合在一起。我的个人库只是在框架类库 (FCL) 上进行了扩展，并实现了我发现 FCL 中缺少的所有功能。它主要包含扩展和帮助类，以及其他高度可重用的类。我发现遵循与 FCL 中相同的命名空间结构非常有用。

我更进一步，开始使用 FCL 的命名空间将我的代码“注入”到我真正期望它们的命名空间中。

一个优点是您不必定义尽可能多的用途。例如。通过简单地引用库，扩展方法立即可用，而无需添加额外的使用。作为一个很好的例子（对于那些喜欢保持其使用列表干净的人），您希望扩展方法多久工作一次，只是意识到您没有添加“using System.Linq;”还没有？

更新：

因此，我认为（如 cmets 中所述）的主要优势是您可以更轻松地访问更多实用程序，而无需查找特定的命名空间。例如。如果您使用的是System.Collections.Generic，则可以使用IList<T> 的立即扩展方法。

我认为这种优势实际上可能超过劣势。我并不担心将来可能会发生名称冲突，因为这表明 FCL 的新版本实际上包含了我想要的类似内容。实际上，它更容易注意到 FCL 中的变化，无论如何我都希望在我的命名空间中反映出来。

当然，我知道如果每个人都开始为公共图书馆这样做会大错特错，但对于我的个人项目，我发现它确实很有用。

我是否忽略了任何其他缺点？我已经考虑过如果我想让图书馆公开，我需要找到一种方法来允许使用 @987654327 @命名空间，或用户需要的不同命名空间。我知道在 .NET 环境中执行此操作的唯一方法是 using predirectives。

更新 2：

所以，就像我说的，我确实意识到有些人可能会觉得这很不方便，并希望使用不同的命名空间。对于我自己的项目，我发现这样做不方便，例如以下：

using System.Windows;
using System.Windows.Controls;
using System.Windows.Media
using System.Windows.Media.Media3D;

using MyNamespace.Windows;
using MyNamespace.Windows.Controls;
using MyNamespace.Windows.Media;
using MyNamespace.Windows.Media.Media3D;

更不用说 this problem 了，例如using MyNamespace.System.Windows;不可能。

提出一个希望得到更有用答案的问题：

有没有比将代码放在 System 命名空间中更好的方法来解决这个问题？有没有一种方法可以在需要时轻松编译到不同的命名空间 ，除了使用前置指令，还是完全是个坏主意？

【问题讨论】：

人们是否在错误地认为更少的代码行等同于更快代码的情况下寻求最小化 using 指令的数量？前几天有人提议编写一个扩展方法来避免必须导入System.Linq 命名空间。我不明白动机。
@Cody：我也不是。如果你不喜欢看你的 using 语句，用代码折叠隐藏它们......它们不会伤害任何东西。
@Cody Gray & @Reed Copsey：我说的优势不是速度，也不是更短的代码。您可以更轻松地访问更多实用程序，而无需查找特定的命名空间。例如。如果您使用的是System.Collections.Generic，则可以使用IList<T> 的立即扩展方法。
为什么首先需要将所有“帮助”函数分离到单独的命名空间中？也就是说，为什么他们不能在MyNamespace 中调用，只剩下一个using 指令要添加？命名空间在这里有用的唯一原因是尽量减少冲突；您的扩展方法是否具有相同的名称是值得怀疑的（如果有，您将无法像您展示的那样同时导入它们）。
@Cody Gray：这是一个很好的论点！不幸的是，它只适用于扩展方法。我还在整个命名空间层次结构中都有辅助类，其中扩展方法是不可能的。（静态函数）对于其余的“工具”类，将它们放在 System 命名空间中的收益并不大。

标签： .net namespaces

【解决方案1】：

忽略命名冲突，因为您已经链接到了...

这有一个主要优点，即您不必定义尽可能多的用途。

我实际上认为这是一个缺点。强制您添加 using 语句或完全限定您的类型使您的代码更易于维护，因为它使定义特定代码的位置更加明显。

虽然您可以在 System.*** 命名空间中查看实用程序，但大多数开发人员会期望定义为 System.***.SomeType 的类型是基类库的一部分。在我看来，用您自己的类型“扩展”基础库会导致混淆，并导致可维护性降低。

【讨论】：

我的措辞选择不当，抱歉。我更新了这个问题，以突出我真正想到的。 ;p
@Steven：这就是我认为你的意思——我的回答仍然适用。通过允许“实用程序”和“扩展”“神奇地出现”，您会降低可维护性，因为它会增加惊喜。
是的，如果不至少允许更改命名空间，我永远不会将其作为公共库发布。虽然，也许有些人喜欢有用的惊喜。 :)
@Steven：就个人而言，我总是将“私人”图书馆视为“公共”图书馆。两年后的我，是一个不同的开发者；）
我完全同意。你不仅是一个不同的开发人员，而且你永远不知道什么时候决定分享你的代码。我不确定区分公共图书馆和私人图书馆是否是一个长期养成的好习惯。

【解决方案2】：

我将发布 Cody Gray 对我帮助最大的评论作为答案：

为什么要分开所有您的“助手”功能分成单独的首先命名空间？那是，他们为什么不能打电话进来 MyNamespace，只剩下一个使用指令添加？唯一的命名空间在这里有用的原因是尽量减少碰撞；值得怀疑您的扩展方法将具有相同的名字（如果他们这样做，你不会能够同时导入它们时间就像你展示的那样）。

【讨论】：