5

哪一个更容易接受（最佳实践）？：

namespace NP
   public static class IO
   public static class Xml
   ...
   // extension methods

using NP;

IO.GetAvailableResources ();

对比

public static class NP
   public static class IO
   public static class Xml
   ...
   // extension methods

NP.IO.GetAvailableResources ();

同样对于#2，代码大小是通过部分类来管理的，因此每个嵌套类都可以在一个单独的文件中，对于扩展方法也是如此（除了它们没有嵌套类）

我更喜欢#2，有几个原因，比如能够使用已经常用的类型名称，比如IO，我不想替换或冲突。

你更倾向哪个？各有什么优缺点？这种情况下的最佳做法是什么？

编辑：两者之间还会有性能差异吗？

4

7 回答 7

3

我会说#1。因为当您将许多类捆绑到一个静态类中时，您会做与命名空间相同的事情。这就是为什么我会说最好让命名空间为你做这件事。

在这种情况下，您还可以通过添加 using in case 来摆脱在所有内容前面写“NP”的麻烦。我认为您应该嵌套命名空间以使它们不会发生冲突，或者使用比 IO 更多的描述命名空间名称。

大多数情况下，最佳实践是微软所做的，我从未见过他们这样做 #2

于 2010-03-15T19:31:02.197 回答
2

我更喜欢#1，因为它不需要我通过 1 个班级打电话到另一个班级。我认为这让事情变得有点混乱，因为通常对象意味着具有成员类、方法等，它们直接处理通过实例化类生成的对象。这意味着您并没有真正遵循 OOP 的原则。微软还说#1 是最佳实践。

于 2010-03-15T19:30:47.827 回答
2

命名空间的全部意义在于它们用于组织您的代码：

命名空间在 C# 程序中以两种方式大量使用。首先，.NET Framework 类使用命名空间来组织它的许多类。其次，声明自己的命名空间有助于控制大型编程项目中类和方法名称的范围。

当您查看 .NET 框架本身时，您会发现几乎所有内容的结构都像您的第一个示例（命名空间），而几乎没有任何结构像您的第二个示例（嵌套类型）。使用嵌套类型的罕见情况是，它们与外部类型紧密相关，以至于它们本质上是外部类型的一部分，但出于代码重用等原因需要成为一个单独的类。

因此，如果您所说的“最佳实践”是指“将事物用于设计目的”、“最像 .NET 框架”和“最接近 .NET 设计范例”，那么就没有争议了；使用命名空间进行组织，而不是嵌套类型。

关于您的编辑 - 不，在现实世界中没有重要的性能差异。

于 2010-03-15T19:33:56.967 回答
1

我从没见过你用过你的2号。它让我想起了 VB6 模块。

于 2010-03-15T19:31:41.990 回答
1

我更喜欢#1，让命名空间来做。就像其他人所说的那样，调用类来访问其他类是非常令人困惑的。

此外，当您执行更复杂的事情（例如反射或使用提供程序模型）时，将嵌套类作为您的实际提供程序部分或您试图达到的目标会变得很麻烦。

最后，测试嵌套类和接口使测试更加困难。

于 2010-03-15T19:36:03.010 回答
0

我认为您应该避免暴露（公共）嵌套类和接口，或者至少 Microsoft FxCop 会这么说。因此，第一个更好。

编辑：（是的，改为第一个，当我累死的时候我不应该回复）

于 2010-03-15T19:30:35.057 回答
0

我实际上发现自己有时会使用#2。我会在下一行之后解释为什么。但是在您使用空静态类的情况下，命名空间更理想，因为这就是它们的用途。

但是，如果您有一个派生新类的用例，有时嵌套这些派生类可能是有意义的。

例如，您可以：

public abstract class Vehicle
{
    int NumberOfWheels;
}

public class SportsCar : Vehicle
{
}

现在，您可能希望将它们都放在 Vehicle 命名空间下，这样父类就不会被所有不同的派生类弄乱。然而，这是个坏主意。

相反，嵌套它们会给您带来所有好处：

public abstract class Vehicle
{
    int NumberOfWheels;

    public class SportsCar : Vehicle
    {
    }
}
于 2014-02-18T01:54:59.950 回答