Angenommen, ich habe eine Klasse 'Bewerbung'. Um initialisiert zu werden, müssen bestimmte Einstellungen im Konstruktor vorgenommen werden. Nehmen wir auch an, dass die Anzahl der Einstellungen so hoch ist, dass es zwingend ist, sie in eine eigene Klasse zu setzen.

Vergleichen Sie die folgenden zwei Implementierungen dieses Szenarios.

Implementation 1:

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

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

Implementation 2:

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

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

Für mich ist der zweite Ansatz sehr zu bevorzugen. Es ist besser lesbar, weil es die Beziehung zwischen den beiden Klassen stark betont. Wenn ich Code schreibe, um die Anwendungsklasse überall zu instanziieren, wird der zweite Ansatz hübscher aussehen.

Nun stellen Sie sich vor, die Settings-Klasse selbst hatte eine ähnliche "verwandte" Klasse, und diese Klasse tat dies auch. Gehen Sie nur drei solcher Ebenen und die Klassennamen werden in dem Fall "nicht verschachtelt" außer Kontrolle geraten. Wenn Sie jedoch nisten, bleiben die Dinge immer noch elegant.

Obwohl ich oben gelesen habe, haben die Leute in StackOverflow gesagt, dass verschachtelte Klassen nur dann gerechtfertigt sind, wenn sie für die Außenwelt nicht sichtbar sind. Das heißt, wenn sie nur für die interne Implementierung der enthaltenden Klasse verwendet werden. Der häufig zitierte Einwand ist, dass die Größe der Quelldatei der enthaltenen Klasse aufgebläht wird. Teilklassen sind jedoch die perfekte Lösung für dieses Problem.

Meine Frage ist, warum wir uns vor der "öffentlich zugänglichen" Verwendung verschachtelter Klassen hüten. Gibt es noch andere Argumente gegen eine solche Verwendung?