扩展FCL的系统名称空间真的是一种糟糕的做法吗？

Question

名称空间是常识 (和公约)用来惟一标识代码和防止名称冲突的，这就是为什么您应该始终将自己的代码放在惟一的名称空间中。

但是 ..。

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

我进一步了，并开始使用FCL的名称空间将我的代码“注入”到我实际上期望它们的命名空间中。

一个优点是，您不必定义这么多用法。例如，通过简单地引用库，扩展方法将立即可用，而无需添加额外的使用。作为一个很好的例子(对于那些喜欢保持使用列表整洁的人来说)，您期望扩展方法工作多久一次，结果却发现您还没有添加“使用System.Linq;”？

更新

因此，我认为(如注释中提到的)的主要优点是，您可以更容易地使用来访问更多的实用程序，而不必查找特定的名称空间。例如，如果您正在使用System.Collections.Generic，则可以立即使用IList<T>的扩展方法。

我认为，这一优势实际上可能大于劣势。我并不担心将来会发生名称冲突，因为这意味着FCL的新版本实际上包含了我想要的类似内容。它实际上使您更容易注意到FCL中的更改，无论如何，我都希望在名称空间中反映这些变化。

当然，我知道如果每个人都开始为公共图书馆做这件事，这将是彻底错误的，但对于我的个别项目，我发现它真的很有用。

我是否忽略了的其他缺点？为了使库公开，我已经考虑过了，我需要找到一种方法，允许使用System命名空间，或者根据用户的需要使用不同的名称空间。我知道在.NET环境中这样做的唯一方法是使用预指令。

更新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;

更别提这个问题了，这使得using MyNamespace.System.Windows;成为不可能。

表达一个希望能给出更多有用答案的问题：

有比将代码放在系统命名空间中更好地解决这个问题的解决方案吗？是否有一种方法可以在需要时轻松地将编译成不同的名称空间，而不是使用预指令，或者这完全是个坏主意？

Answer 1

我会贴出科迪·格雷对我最有帮助的评论，作为回答：

为什么首先需要将所有“助手”函数分离到单独的命名空间？也就是说，为什么他们不能在MyNamespace中调用be，而只剩下一个使用指令添加呢？名称空间在这里有用的唯一原因是尽量减少冲突；扩展方法是否会有相同的名称是值得怀疑的(如果是这样，那么您就不能像已经显示的那样同时导入它们)。

Answer 2

忽略名字冲突，因为你已经联系到了.

这有一个很大的优势，你不必定义很多用法。

实际上我认为这是一种劣势。强制您添加using语句或完全限定您的类型会使您的代码更易于维护，因为它使定义特定代码的地方更加明显。

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