.net - 扩展 FCL 的系统命名空间真的是一种不好的做法吗？

Question

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

但是，...

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

我更进一步，开始使用 FCL 的命名空间将我的代码“注入(inject)”到我实际期望的命名空间中。

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

更新:

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

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

当然，我知道如果每个人都开始为公共(public)图书馆这样做，那将是根本错误的，但对于我的个人项目，我发现它确实很有用。

我是否忽略了任何其他缺点？我已经考虑过如果我想公开库，我需要找到一种方法来允许使用 System 命名空间，或用户需要的不同命名空间。我知道在 .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; 不可能。

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

有没有比将代码放在系统命名空间中更好的解决方案？有没有办法在需要时轻松编译到不同的命名空间 , 除了使用预指令，还是这完全是个坏主意？

Answer 1

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

This has a major advantage that you don't have to define as many usings.

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

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