10

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

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

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

  1. 有一个DrawingUtils班级和一个DiagnosticsUtils班级，但这只是闻起来像糟糕的结构。
  2. 选择一个词库，然后用一个更糟糕、更长或尴尬的名字来完成，而这个名字还是随便不被使用的。
  3. 用我的母语而不是英语写班级名称。
  4. 问问 StackOverflow 的聪明人。

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

编辑：

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

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

编辑2：

下次看看的另一个解决方案：扩展方法（由Lawnmower提供）。

4

7 回答 7

8

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

于 2010-08-06T14:03:22.463 回答
6

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

using MyAlias = My.Custom.Namespace;

这将使您的课程与微软的课程分开。

然后您可以将您的课程引用为

MyAlias.Diagnostics

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

于 2010-08-06T14:04:15.963 回答
5

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

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

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

于 2010-08-06T14:02:49.797 回答
4

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

using Type = MyReallyCoolCustomReflector.Type;

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

System.Type sysType = anObject.GetType();

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

于 2010-08-06T14:04:51.303 回答
1

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

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

例子：

如果你正在创建一个数学类，你可以命名你的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;
        }
    }
}
于 2010-08-06T14:11:17.503 回答
1

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

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

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

于 2010-08-06T14:16:18.760 回答
1

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

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

一般来说：

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

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

  3. 甚至不要考虑这个...

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

于 2010-08-06T14:20:56.317 回答