私有嵌套静态类 - 好还是坏的做法？答案

【问题标题】：Private nested static class - Good or bad practice?私有嵌套静态类 - 好还是坏的做法？
【发布时间】：2011-12-25 19:42:45
【问题描述】：

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

public class Outer
{
    private static class Inner
    {


    }
}

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

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

    private class Inner
    {


    }
}

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

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

【问题讨论】：

【解决方案1】：

这根本没有错，为什么会有呢？

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

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

【讨论】：

【解决方案2】：

这两种方法都完全有效。

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

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

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

这取决于Inner 类的作用。如果它只是一个实用程序类静态内部类是要走的路。

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

另外，如果Inner类与其他对象复合，则不应该是静态类。

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

【讨论】：

【解决方案5】：

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

【讨论】：

【解决方案6】：

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

不，不要想象。

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

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

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

这是降低复杂性的方法。

【讨论】：