C#名称空间：如何遵循标准而不引起恼人的冲突？

我正在研究一个C#library（为了这个问题，我们就叫它“Foo”）。它有一些与标准.NET需求非常相似的需求：例如，它提供一些绘图服务和一些转换服务

为了熟悉和让库的用户能够猜出东西的名称，我希望遵循.NET标准，并将库的这些部分命名为Foo.Drawing和Foo.Convert（等等）。但我发现在实际使用中，这会引起疼痛。人们几乎总是在每个文件的顶部有“using System；”，当使用这个库时，他们也希望有“using Foo；”。但现在他们有了两个绘图模块和两个转换模块，欢闹随之而来

例如，现在，您必须显式拼写System.Drawing.Color，而不是仅使用Drawing.Color作为参数或变量类型，否则编译器会抱怨Foo.Drawing没有颜色类型。类似地，如果要使用标准Convert.ToInt32，即使您已经在使用System，也必须使用System.Convert.ToInt32，因为否则它会找到Foo.Convert，而找不到ToInt32

我理解这一切的原因，但我对C#社区还是新手，所以我不知道哪种解决方案是最标准的：

保持这种方式，并期望用户在必要时使用完全限定的名称

将冲突模块重命名为其他模块（可能是Foo.Graphics而不是Foo.Drawing，或者是Foo.Conversion而不是Foo.Convert）

在标准名称上使用一些前缀（Foo.FDrawing和Foo.FConvert）

还有别的吗

---

任何来自更有经验的C#gurus的建议都将不胜感激

您可以使用命名空间别名：

using System;
using FConvert = Foo.Convert;

public class Bar
{
     public void Test()
     {
          var a = Convert.ToInt32("1");
          var b = FConvert.ToInt32("1");
     }
}

---

名称空间的主要用途之一是避免名称冲突

这意味着名称空间允许开发人员创建具有相同名称的类型，只要这些类型属于不同的名称空间

一个库通常至少有一个根名称空间，可能还有嵌套的名称空间，可以对相关类型进行逻辑分组

只要名称有意义并代表类型的真正含义，就可以根据需要命名类型。库的客户端希望名为
Animal
的类型表示
Animal
，而不是其他类型。这同样适用于命名名称空间

但是，要不惜一切代价避免使用
系统中的名称
，因为对于您的图书馆客户（如您所述）来说，处理各地相互冲突的名称会非常烦人

处理类内冲突的名称空间的一种常见方法是使用名称空间别名：

 using FooConvert = Foo.Convert;
 using BarConvert = Bar.Convert;

我不清楚你的意思-是
Foo.Drawing
另一个名称空间，还是类型？我肯定会尽量避免在
系统中出现与公共类型冲突的类型名
…我为每个库选择一个名称空间。为什么
绘图
是一个问题？没有
System.Drawing
类。有一个System.Drawing命名空间（），还有一个Foo.Drawing命名空间，这是导致使用Foo比应该的更烦人的几个冲突之一。等等，不，这不太正确。画画是一门课。System.Drawing是一个名称空间，而不是一个类，但我看不出这有什么帮助--当我在Foo名称空间中并尝试使用（比如）Drawing.Color时，我仍然会遇到冲突，因为编译器似乎在寻找Foo.Drawing.Color，而它并不存在。好的，我很感谢您花时间编写这样一个好的解释，但我真的觉得不清楚该怎么办。你的“不惜一切代价避免系统中的名字”建议符合我自己的直觉。。。那我该怎么办呢？让我们以转换为例；当然，库中有需要转换的类型并不少见。我应该将其命名为Convert并让人们使用名称空间别名（或完全限定名）来处理它，还是将其命名为其他名称以避免冲突？