c# - "Public"是否嵌套类

Question

假设我有一个“应用程序”类。为了被初始化，它需要在构造函数中进行某些设置。我们还假设设置的数量如此之多，以至于不得不将它们归为一类。

比较此场景的以下两个实现。

实现 1:

class Application 
{
   Application(ApplicationSettings settings) 
   {
       //Do initialisation here
   }
}

class ApplicationSettings 
{
   //Settings related methods and properties here
}

实现 2:

class Application 
{
   Application(Application.Settings settings) 
   {
       //Do initialisation here
   }

   class Settings 
   {
      //Settings related methods and properties here
   }
}

对我来说，第二种方法更可取。它更具可读性，因为它强烈强调了两个类之间的关系。当我编写代码在任何地方实例化 Application 类时，第二种方法看起来会更漂亮。

现在想象一下 Settings 类本身有一些类似的“相关”类，而那个类反过来也有。只有三个这样的级别，类命名在“非嵌套”情况下会失控。然而，如果你嵌套，事情仍然保持优雅。

尽管如此，我还是在 StackOverflow 上看到有人说嵌套类只有在它们对外界不可见时才是合理的；也就是说，如果它们仅用于包含类的内部实现。经常被引用的反对意见是膨胀包含类的源文件的大小，但分部类是解决该问题的完美解决方案。

我的问题是，为什么我们对嵌套类的“公开暴露”使用持谨慎态度？还有其他反对这种使用的理由吗？

Answer 1

我觉得还行。这基本上是构建器模式，使用嵌套类效果很好。它还允许构建器访问外部类的私有(private)成员，这可能非常有用。例如，您可以在构建器上使用 Build 方法，该方法调用外部类上的私有(private)构造函数，该类采用构建器的实例:

public class Outer
{
    private Outer(Builder builder)
    {
        // Copy stuff
    }

    public class Builder
    {
        public Outer Build()
        {
            return new Outer(this);
        }
    }
}

这确保了构建外部类实例的唯一方式是通过构建器。

我在 Protocol Buffers 的 C# 端口中使用了一个非常像这样的模式。