问“公共”嵌套类或不嵌套类

EN

假设我有一个'Application‘类。为了被初始化，它需要在构造函数中进行某些设置。让我们也假设设置的数量是如此之多，以至于必须将它们放在它们自己的类中。

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

实施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上读到有人说，只有当嵌套类对外部世界不可见时，它们才是合理的；也就是说，如果它们只用于包含类的内部实现。通常被引用的反对意见是包含类的源文件的大小膨胀，但分部类是这个问题的完美解决方案。

我的问题是，为什么我们对“公开暴露”的嵌套类的使用保持警惕？还有没有其他的理由反对这样的使用？