Class.Class vs Namespace.Class用于顶级通用类库?

时间:2010-03-15 19:20:22

标签: c# .net class nested-class

哪一个更容易被接受(最佳实践)?:

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,我不想替换或碰撞。

您更喜欢哪一个?各有利弊吗?这种情况的最佳做法是什么?

编辑:两者之间是否会有性能差异?

7 个答案:

答案 0 :(得分:3)

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

在这种情况下,您还可以通过在需要时添加使用来摆脱必须在所有内容中编写“NP”。我认为您应该嵌套您的命名空间,以便它们不会碰撞或使用更多描述命名空间名称而不是IO。

大多数情况下,最好的做法是微软所做的,我从未见过他们做过#2

答案 1 :(得分:2)

我更喜欢#1,因为它不需要我通过1个类来调用另一个类。我认为它使事情有点混乱,因为通常对象意味着有成员类,方法等直接处理通过实例化类所做的对象。这意味着你并没有真正遵循OOP的原则。微软还表示#1是最佳做法。

答案 2 :(得分:1)

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

答案 3 :(得分:1)

whole point of namespaces is that they are used to organise your code

  

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

当您查看.NET框架本身时,您可以看到几乎所有内容都像您的第一个示例(命名空间)一样构建,并且几乎没有任何内容像第二个示例(嵌套类型)那样构建。使用嵌套类型的罕见情况是它们与外部类型紧密相关,它们本质上是它的一部分,但由于代码重用等原因需要成为一个单独的类。

因此,如果通过“最佳实践”,您的意思是“将内容用于设计目的”,“最像.NET框架”和“最接近.NET设计范例”那么就没有竞争;将名称空间用于组织,而不是嵌套类型。

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

答案 4 :(得分:1)

我更喜欢#1并让命名空间来做。就像其他人所说的那样,调用课程去其他课程是非常困惑的。

此外,当您执行更复杂的事情(如反射或使用提供者模型之类的东西)时,将嵌套类作为您的实际提供者部分或您尝试访问的目标变得毛茸茸。

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

答案 5 :(得分:0)

我认为你应该避免暴露(公共)嵌套类和接口,或者至少这是微软FxCop会说的。因此,第一个更好。

编辑:(是的,改为第一个,当我累死时我不应该回复)

答案 6 :(得分:0)

我实际上发现自己有时使用#2。我会在下一行之后找到原因。但在你的情况下,使用空的静态类,命名空间更理想,因为它就是它们的用途。

但是,如果您有一个用于派生新类的用例,有时可能会嵌套这些派生类。

例如,您可以:

public abstract class Vehicle
{
    int NumberOfWheels;
}

public class SportsCar : Vehicle
{
}

现在,您可能希望将它们都置于Vehicle名称空间下,以便父级不会混乱所有不同的派生类。但是,这是一个bad想法。

相反,嵌套它们可以带来所有好处:

public abstract class Vehicle
{
    int NumberOfWheels;

    public class SportsCar : Vehicle
    {
    }
}