私有嵌套静态类-好或坏的做法

本文关键字：嵌套 静态类 | 更新日期: 2023-09-27 18:14:05

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

public class Outer
{
    private static class Inner
    {

    }
}

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

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

    }
}

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

我必须承认，我几乎从来没有使用过嵌套类，无论是静态的还是非静态的，但是我对这个特殊的概念很感兴趣。

私有嵌套静态类-好或坏的做法

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

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

我见过的一个非常常见的例子是枚举对象——它们可能相当复杂，特别是当你开始构建可以链接的自定义迭代器时，比如LINQ。将复杂性隐藏在单个类中就是封装的定义。

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

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

想象一下需要构建一个类，它的复杂性相当于一个小的应用程序…使用完全位于复杂内部的类外部类

不，别想了。

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

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

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

这完全没有错，为什么会有错呢?

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

这取决于Inner类做什么。如果它只是一个实用程序类，静态内部类是最好的选择。

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

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

public class Car
{
    private class Engine
    {
        // your code here
    }
}
相关文章：