Question

将私有静态类嵌套在非静态类中会被视为不好的做法吗？

public class Outer
{
    private static class Inner
    {


    }
}

这里的想法是'Outer'的所有实例都将共享对静态的访问。另一种方法可能是让Inner类是非静态的并使用它的静态实例：

public class Outer
{
    private static innerInstance = new Inner(); 

    private class Inner
    {


    }
}

类似的效果。这种方法有哪些优缺点或其他考虑因素？

我必须承认，我几乎从不使用嵌套类，无论是否静态，但我对这个特定的概念感兴趣..

Answer 1

这两种方法都是完全有效的。

我希望开发人员更频繁地使用私有嵌套类。结合c＃的partial关键字，它使编写非常复杂的类更易于维护。想象一下，需要构建一个具有小型应用程序复杂性的类 - 当您实际上可以构建一个完整的私有应用程序时，会更加容易，其中的类完全在您的复杂外部类中！

我见过的一个非常常见的案例是enumerables - 这些可能非常复杂，尤其是当您开始构建可以链接的自定义迭代器时，例如LINQ。隐藏单个类中的复杂性是封装的定义。

Answer 2

如果在多线程应用程序中使用该类，则可能需要通过锁定来控制对静态的访问。无论是否私密嵌套，这都是静态问题。

Answer 3

这对此没有任何不妥，为什么会这样？

范围是有限的，因此只有外部类的实例才能访问它，并且它是放置常量和其他常用功能的好地方，这些功能对于外部类的功能是私有的，而不必将其全部实例化时间。

我认为这不是好事。

Answer 4

原则上它没有任何问题，但是如果你想要一个嵌套的静态类来帮助组织静态状态或方法，它可能是一个警告标志，这个类变得太大了。嵌套的私有类有很多用途（内部数据结构，传出私有接口的私有实现等），但静态私有类实际上只是将事物组合在一起的一种方式。

Answer 5

想象一下，需要构建一个复杂程度不高的类应用程序...具有完全属于您的复合体的内部类外层阶级

不，不要想像。

即使是小型应用程序，也不要构建具有应用程序复杂性的类。

这样做，实际上会增加复杂性。

使用单独的类，理想情况下，每个类都有一个职责。

这是降低复杂性的方法。

Answer 6

这取决于Inner班级做什么。如果它只是一个实用程序类，则静态内部类是可行的。

public class Calculator
{
    private static class HexToDecUtils
    {
        // converter code here
    }
}

换句话说，如果Inner类与其他对象合成，则它不应该是静态类。

public class Car
{
    private class Engine
    {
        // your code here
    }
}