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

Posted 2023-03-16

【中文标题】我应该使用与 .NET BCL 的名称冲突的（否则是最佳的）类名称吗？

【英文标题】：Should I use (otherwise optimal) class names that conflict with the .NET BCL's names?

【发布时间】：2011-03-26 08:45:44

【问题描述】：

这种情况对你们中的某些人来说可能并不罕见：你有一些功能可以放入一个类中，但该类的完美名称 (*) 由 System 命名空间或其他命名空间中的一个类使用/class 这不是你的，但你是 using/importing。

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

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

有一个DrawingUtils 类和一个DiagnosticsUtils 类，但这听起来像是结构不好。 选择一个词库，然后用一个更糟糕、更长或尴尬的名字来完成，而这个名字还是随便不被使用的。 用我的母语而不是英语写班级名称。 请教 *** 的聪明人。

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

编辑：

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

在实践中，这意味着："Drawing"：吸引人的东西。"MyCustomControlDrawing"：仅在MyCustomControl 上吸引人的东西。例如："WidgetDrawing".

编辑2：

下次再看看另一个解决方案：Extension Methods（由Lawnmower提供）。

【问题讨论】：

"L'art pour l'art" - 为艺术而艺术。这就是我对你的问题的看法。解决方案 1 很好，为什么不应用它呢？我认为我们的日常工作中存在更重要的问题：P

@Łukas：如果我一生中成功解决了一个小问题，那么下次我遇到同样的问题时，我会更快地找到解决方案。

我不这么认为.. 有一天我也认为一些问题有完美的解决方案，如果我发现它，那么我以后会知道如何解决这些问题......不是这样的..不同的项目，不同的人在做这件事，所有的规则都不会像这里那样完整；）我不反对这样的问题；）这是一个很好的问题..请注意那些答案不是终极的；）

【参考方案1】：

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

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

一般：

这就是我们正在做的事情（嘿，我们可以稍后对其进行重构）

使用过一次或两次，但只在重要课程上使用。如果您还不知道“完美”的名称，则特别有用。

别想这个……

使用命名空间别名并不好玩。所以我尽量避免。

【讨论】：

我的一个“Utils.Drawing”是一个方便的用于快速 setPixel() 的 lockbits 包装器。另一个是 RGBHSL 工具。恕我直言，这些应该在 System.Drawing 命名空间中。

根据他们处理的数据类型，您可能需要考虑扩展方法。然后类名不再有影响。我会将 RGBHSL 放入一个单独的 ColorSpaceConverter 类中。不管怎样，迟早你会需要更多的色彩空间:)

嗯，谢谢推荐。我来看看扩展方法！ :)

【参考方案2】：

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

我个人不喜欢像 Utils 这样的通用类，因为它们的方法不是很容易被发现（而且通常太笼统或太具体），因此我认为它们仅用于内部类是合理的。

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

【讨论】：

我从不使用来自不同程序集的“Utils”之类的东西，它是内部的东西。

PS：我有没有说过Diagnostics namespace？

@Camilo Martin，不，你没有。我只是下意识地回忆了为什么一个shouldn't name a class as its namespace...但无论如何它与你的情况无关。

【参考方案3】：

好吧，如果你想避免命名空间冲突，你可以做几件事：

---

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

示例：

如果你正在创建一个数学类，你可以将你的命名为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;
        
    

【参考方案4】：

使用命名空间来区分您的类与其他命名空间中的类。要么使用完全限定的名称，要么使用告诉编译器你需要什么的 using 语句：

using Type = MyReallyCoolCustomReflector.Type;

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

System.Type sysType = anObject.GetType();

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

【讨论】：

之所以选择答案，是因为您已经说得很清楚了：“这是一个权衡”。

【参考方案5】：

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

using MyAlias = My.Custom.Namespace;

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

然后您可以将您的类引用为

MyAlias.Diagnostics

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

【讨论】：

这正是我使用 Microsoft 尝试使用的类名的方式。

这在实践中很烦人。我总是忘记添加行。 VS 不会使用添加所有其他使用行的普通快捷方式自动执行此操作。如果阅读使用别名的代码很容易混淆。如果您需要来自两个命名空间的两个类，您的代码就会被 Mycompany.myproject.mysubproject.mymodule.MyClass 弄得一团糟。不用了，谢谢。我宁愿取一个不那么完美的名字。

我实际上在使用 WPF Toolkit 数据网格和内置数据网格控件的 WPF 应用程序时遇到了这个问题。我不得不给 Microsoft.Windows.Controls 取别名，因为它有许多 System.Windows.Controls 的名称。我同意这有点烦人，但同样的事情也适用于将“Utils”附加到每个类名。

【参考方案6】：

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

【讨论】：

嗯，这就是我对 Diagnostics 的看法，但我会广泛使用两个不同的“Drawing”类，并且彼此接近。

【参考方案7】：

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

老实说，提出有意义的标识符名称是一项有用的技能，但不值得延迟您的开发。如果你不能很快想出好的东西，那就满足于平庸的东西并继续前进。辛辛苦苦命名这些名字没有什么价值。我敢说你可以做更多富有成效的事情。

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

【讨论】：

特别是考虑到在现代开发环境中重命名事物是多么容易。有时，在您使用它一段时间之前，您不会想到一个完美的名称。

不知道为什么不赞成但对我来说小是简洁的一个组成部分。我讨厌小名字，但非常长的行几乎同样不利于可读性。

小而简洁是不同的术语。简洁准确地描述了一个在保持简洁的同时传达大量信息的术语。我会告诫不要仅仅为了使用一个小名称而使用“小”术语。在可读性方面肯定有一个平衡。

我说小和简洁和清楚，除了brief=small。当然，它应该很长如果需要。

嗯，不完全是。你说小是简洁的一个组成部分。这是事实，也是澄清的原因。区别很重要。简洁是可取的，但为了简洁而不是简洁。