我是否应该使用与 .NET BCL 名称冲突的（否则最佳的）类名称？

Question

这种情况对于某些人来说可能并不完全罕见：您有一些功能可以放入类中，但该类的完美名称 (*) 被 System 命名空间中的类之一采用，或者其他不属于您的命名空间/类，但您正在使用/导入。

(*) 我所说的完美是指小、简洁和清晰的名称。

例如，我有一个 Utils 类，它有一个 Diagnostics （主要是调试 utils） ) 类和一个 Drawing 类。我可以：

1. 有一个 DrawingUtils 类和一个 DiagnosticsUtils 类，但这听起来像是糟糕的结构。
2. 选择一个同义词库，然后使用一个更差、更长或尴尬的名字，但仍然没有被随意采用。
3. 用我的母语而不是英语写班级名称。
4. 询问 StackOverflow 上的聪明人。

我认为选项 1-3 没有希望:(

编辑：

由于我选择的答案没有明确解决问题（我也没有），对于面临相同情况的人的建议是问问自己：您会经常使用冲突的 BCL 类/命名空间吗？如果不是，那么就让您的名称发生冲突（就像我在 Diagnostics 中所做的那样），如果是，请添加一个词来限制您的可能性。实际上

，这意味着：
“绘图”：可以绘制的东西。
“MyCustomControlDrawing”：仅在 MyCustomControl 上绘制的内容。例如：“WidgetDrawing”。

EDIT2：

下次看一下另一个解决方案： 扩展方法 （由割草机）。

Answer 1

我不认为保留名称 Drawing、Diagnostics 等有任何问题。这是命名空间的目的之一，解决命名冲突。

Answer 2

命名空间的美妙之处在于它们允许您创建具有相同名称的类。当您使用 using 语句将名称空间导入到文件中时，您可以为其分配别名。

using MyAlias = My.Custom.Namespace;

这将使您的课程与 Microsoft 的课程分开。

然后，您可以引用您的类，

MyAlias.Diagnostics

或者您也可以为 Microsoft 的命名空间分配一个别名，但我不推荐这样做，因为它会让其他开发人员感到困惑。

Answer 3

对我来说，故意编写冲突的类名确实不值得。您会让不熟悉您的代码库的其他开发人员感到困惑，因为他们希望使用 BCL 类，但最终却使用您的类（反之亦然）。然后，当他们必须使用别名编写特定的代码时，您只是浪费他们的时间。

老实说，提出有意义的标识符名称是一项有用的技能，但不值得推迟您的开发。如果你不能很快想出一些好的东西，那就接受一些平庸的东西然后继续前进。为这些名字而苦苦挣扎没有什么价值。我敢说你可以做更多更有成效的事情。

编辑：我也不相信“小”是“完美”标识符的组成部分。当然，简洁明了，但如果需要更长的名称来传达特定结构的目的，那就这样吧。毕竟我们有智能感知。

Answer 4

使用命名空间来消除您的类与其他命名空间中的类的歧义。使用完全限定名称或使用语句来告诉编译器您需要什么：

using Type = MyReallyCoolCustomReflector.Type;

现在，如果您仍想使用 System 命名空间中的 Type 类：

System.Type sysType = anObject.GetType();

一般来说，我会尝试避免名称重复，但这并不总是这样。我也喜欢简单、可读和可维护的代码。因此，这通常是一个权衡决定。

Answer 5

好吧，如果您想避免命名空间冲突，您可以执行以下操作：

---

• 不要冲突，而是选择一个唯一的名称。

示例：

如果您要创建一个 Math 类，您可以将其命名为 CamiloMartin.MathHelper

---

• 使用长命名空间来区分碰撞。

示例：

public class MyClass
{
    public int SomeCalculation(int a, int b)
    {
        return MyNamespace.Math.SomeFunc(a, b);
    }
}

---

• 使用别名来区分。

示例：

using System.Math;
using SuperMath = MyNamespace.Math;

namespace MyNamespace
{
    public class MyClass
    {
        public int SomeCalc(int a, int b)
        {
             int result = Math.abs(a);
             result = SuperMath::SomeFunc(a, b);

             return result;
        }
    }
}

Answer 6

仅供记录：.NET 框架既没有 Utils 也没有 Diagnostics 类。 （但确实有 System.Diagnostics 命名空间。）

就我个人而言，我不喜欢像 Utils 这样的通用类，因为它们的方法不是很容易发现（通常要么太笼统，要么太具体），因此我只会证明它们的使用是合理的对于内部类。

至于其余的——我同意其他人的观点，即命名空间很方便。 （虽然如果 System 中已经有一个同名的类，我会三思而后行，不是因为名称冲突，而是因为我不能使用“original” class 可能意味着我要创建的类在语义上是不同的。）

Answer 7

通常可以选择更具体的名称。以Utils为例。绝对一切都可以称为实用程序。对于代码的读者来说，这个类名毫无价值。

通常，实用程序类是一些并不真正适合其他地方的方法的集合。尝试将它们放在它们所属的位置，或按某些标准对它们进行分组，然后使用该组作为类名。根据我的经验，这种分组总是可能的。

一般来说：

1. 这就是我们正在做的事情（嘿，我们可以稍后重构它）

2. 使用它一次或两次，但仅在重要的情况下使用它类。如果您还不知道“完美”名称，则特别有用。

3. 别想这个...

使用命名空间别名一点也不好玩。所以如果可以的话我会避免它。