C# 私有嵌套静态类-好的还是坏的实践？

将私有静态类嵌套在非静态类中会被认为是一种不好的做法吗

public class Outer
{
    private static class Inner
    {


    }
}

这里的想法是，“外部”的所有实例都将共享对静态的访问。另一种方法可能是让内部类成为非静态类，并使用它的静态实例：

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

    private class Inner
    {


    }
}

类似的效果。这种方法的优点/缺点或其他考虑因素是什么

---

我必须承认，我几乎从不使用嵌套类，不管是静态的还是非静态的，但我对这个特定的概念感兴趣。

这一点都没有错，为什么会有呢

范围是有限的，因此只有外部类的实例可以访问它，并且它是放置常量和其他外部类功能专用的公共功能的好地方，而不必一直实例化它

---

我只认为这是一种好的做法。

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

我希望开发人员更多地使用私有嵌套类。结合c#的关键字，它使编写非常复杂的类更易于维护。想象一下，需要构建一个具有小型应用程序复杂性的类——当您实际可以构建一个完整的私有应用程序时，使用完全位于复杂外部类内部的类会容易得多

---

我看到的一个非常常见的情况是——这些可能非常复杂，特别是当您开始构建可以链接的自定义迭代器时，如。将复杂性隐藏在单个类中正是封装的定义。

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

这取决于

内部的
类做什么。如果它只是一个实用类，静态内部类是一个不错的选择

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

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

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

原则上它没有问题，但是如果您想要一个嵌套的静态类来帮助组织静态状态或方法，那么它可能是一个警告信号，表明该类变得太大了。嵌套的私有类有很多用途（内部数据结构、传递的私有接口的私有实现等），但静态私有类实际上只是一种将事物组合在一起的方法

想象一下，需要构建一个具有小型应用程序复杂性的类
应用使用完全在您的复合体内部的类
外层阶级

不，别想象

只是不要构建一个具有应用程序复杂性的类，即使是一个小应用程序

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

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

这是降低复杂性的方法。
如果不需要访问外部类的成员，静态类的效率更高。因此Linkedlist.java中的
节点
是静态的。查找有效的java