顶级通用类库的 Class.Class 与 Namespace.Class？

Question

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

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

using NP;

IO.GetAvailableResources ();

vs

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

NP.IO.GetAvailableResources ();

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

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

你更喜欢哪一个？各自有什么优点和缺点吗？此案例的最佳实践是什么？

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

我更喜欢#1，因为它不需要我通过一个类调用来到达另一个类。我认为这让事情有点混乱，因为一般来说，对象应该具有成员类、方法等，它们直接处理通过实例化类创建的对象。这意味着您并没有真正遵循 OOP 的原则。微软还表示#1 是最佳实践。

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

例如，您可以：

public abstract class Vehicle
{
    int NumberOfWheels;
}

public class SportsCar : Vehicle
{
}

现在，您可能希望将它们都放在 Vehicle 命名空间下，以便父类不会因所有不同的派生类而混乱。但是，这是一个 坏主意。

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

public abstract class Vehicle
{
    int NumberOfWheels;

    public class SportsCar : Vehicle
    {
    }
}