Предположим, у меня есть класс «Приложение». Для инициализации требуются определенные настройки в конструкторе. Давайте также предположим, что количество настроек настолько велико, что вынуждает их размещать в своем собственном классе.

Сравните следующие две реализации этого сценария.

Реализация 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, что вложенные классы оправданы, только если они не видны внешнему миру; то есть если они используются только для внутренней реализации содержащего класса. Обычно цитируемым возражением является раздувание размера исходного файла класса, но частичные классы являются идеальным решением для этой проблемы.

Мой вопрос: почему мы опасаемся "публичного" использования вложенных классов? Есть ли другие аргументы против такого использования?