2

在我工作过的所有公司中，我最终都支持一组核心库，这些库无非是增强和扩展 .net 库。通常我有这样的命名空间，它们以我们的公司名称开头，但子命名空间反映了命名空间的那些System。

Foo.IO;
Foo.Web

我打算做的是更进一步，用系统命名空间替换公司命名空间，这样你只需要一个 using 语句，从而更好地增强核心库。

namespace System.IO
{
    public static class StreamExtensions
    {
        ...
    }
}

实际问题

现在我知道这是可能的，微软在他们自己的库中做到了，我已经看到它在其他第三方库中做到了，但我想知道的是，如果有的话，这样做的长期影响是什么，比如一个类.net 更高版本中的名称冲突？有没有人这样做并且不得不处理一个复杂的问题，它破坏了仅仅能够添加程序集引用的简单性？

更新

不幸的是，这变成了更多关于你是否应该这样做的辩论，这可能属于程序员。不雅地还有另一个SO question确实问了这个问题，但这不是问题的重点。

我想知道是否存在会导致编译错误或奇怪行为的场景。唯一出现的两个论点是。

  1. Microsoft 将方法添加到与库中扩展方法的签名相匹配的对象，但这是一个静音点，因为它不会影响扩展方法所在的命名空间，因为对象上的实现将优先。

  2. 其他人在他们的第三方库中做同样的事情，我们有一个名字冲突。这更有可能是我们已经必须处理的事情，第三方库 ILMerge 其他库到他们的程序集中。

需要明确的是，这是一个独立的库，它是供内部使用的，不能在外部使用，并且可以通过扩展方法扩展现有的系统库。

4

3 回答 3

2

我建议不要这样做。System命名空间是 .NET Framework 命名空间，如果要从该命名空间自定义类，请在代码中明确说明。

这意味着使自定义类成为您自定义命名空间的一部分。

不要把事情搞砸。

于 2012-05-15T13:22:33.757 回答
2

这可能有点离题，但参考您提到的替代方法：

通常我有命名空间，它们以我们的公司名称开头，但子命名空间反映了系统命名空间的命名空间。

我对这种方法有一些问题。

我的公司名称是 Resolv - 因此，我写的很多东西最终都会以 Resolv.<ProjectName> 的形式进入命名空间（其余的将是 <ClientName>.<ProjectName>）。

我开始在名为 Resolv.System 的命名空间中构建我的扩展方法、静态类等库

但是，当使用以 System 开头的“完全限定”类型名称（例如var myVar = new System.Collections.List<int>()；）时，这会产生命名空间解析问题。

虽然在这种特殊情况下我永远不会使用完全限定的名称，但如果我引用的类型是整个代码文件中该名称空间中唯一的类型（在这种情况下添加 ausing是没有保证的） ，我有时会这样做- 或者在导入的两个命名空间（使用 using 语句）包含冲突的类型名称的情况下。当没有适当的using语句时，自动代码生成工具（如 resharper）通常会添加这些类型的引用。

如果我在Resolv 中的任何位置（例如 Resolv.MyInternalProject）中的某个名称空间中处理代码——并且我输入了应该是完全限定的名称——由于 Resolv.System 名称空间而导致混淆。编译器返回当前命名空间，到达 Resolv，然后找到 Resolv.System。这意味着——例如——new System.Collections.List<int>()将尝试使用不存在的类Resolv.System.Collections.List<int>()。

当然，我可以通过使用表单来解决这个问题，var myVar = new global::System.Collections.List<int>()但这很丑而且有点痛苦）。

我选择在我的扩展命名空间树中包含一个“项目名称”，所以现在Resolv.System我没有Resolv.Extensions.System. 从那里子命名空间镜像系统命名空间（例如Resolv.Extensions.System.IO）。这样，我可以更好地控制是否要让 System.xxx.xxxx 引用引用我的扩展名，或者任何给定代码文件中的 .net 引用（并且当我需要时，它只是一个 using 语句添加到我的代码文件中“打开扩展”）。

当然，在处理 Resolv.Extensions 命名空间内的代码时，我仍然会遇到 System.xxx.xxx 命名空间混乱——但这不会让我每天都感到烦恼！:)

于 2012-10-13T01:47:41.563 回答
0

我打算做的是更进一步，用系统命名空间替换公司命名空间，这样你只需要一个 using 语句，从而更好地增强核心库。

我不明白这将如何增强核心库。当 Microsoft 将相同的方法添加到String类中并执行完全不同的操作时会发生什么？这就是他们应该在自己的命名空间中的原因。

现在我知道这是可能的，微软在他们自己的库中做到了，我已经看到它在其他第三方库中做到了，但我想知道的是，如果有的话，这样做的长期影响是什么，比如一个类.net 更高版本中的名称冲突？

长期影响是，如果 Microsoft 将与您创建的扩展方法相同的方法添加到类中。

有没有人这样做并且不得不处理一个复杂的问题，它破坏了仅仅能够添加程序集引用的简单性？

我不明白您要减少参考数量的原因。这样做你什么也得不到，在自己的命名空间和类中拥有实用程序方法是一个有效的设计决策，人们认为它们将是独立的，而不是 Microsoft 命名空间的一部分。

这是一个有效的陈述，但问题是什么意思。其他人，包括我自己，因为对弄乱别人的命名空间有一种“直觉”的感觉而回避这样做，但没有人因此而说不要这样做。如果你有一个具体的事实原因，我很想听听。

这意味着开发人员假设 System 命名空间仅填充了 Microsoft 代码。

于 2012-05-15T13:43:31.967 回答