Question

Suppose I have a class ‘Application’. In order to be initialised it takes certain settings in the constructor. Let’s also assume that the number of settings is so many that it’s compelling to place them in a class of their own.

Compare the following two implementations of this scenario.

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    } } 

To me, the second approach is very much preferable. It is more readable because it strongly emphasises the relation between the two classes. When I write code to instantiate Application class anywhere, the second approach is going to look prettier.

Now just imagine the Settings class itself in turn had some similarly ‘related’ class and that class in turn did so too. Go only three such levels and the class naming gets out out of hand in the ‘non-nested’ case. If you nest, however, things still stay elegant.

Despite the above, I’ve read people saying on StackOverflow that nested classes are justified only if they’re not visible to the outside world; that is if they are used only for the internal implementation of the containing class. The commonly cited objection is bloating the size of containing class’s source file, but partial classes is the perfect solution for that problem.

My question is, why are we wary of the ‘publicly exposed’ use of nested classes? Are there any other arguments against such use?

Answer 1

I think it’s fine. This is basically the builder pattern, and using nested classes works pretty well. It also lets the builder access private members of the outer class, which can be very useful. For instance, you can have a Build method on the builder which calls a private constructor on the outer class which takes an instance of the builder:

public class Outer {     private Outer(Builder builder)     {         // Copy stuff     }      public class Builder     {         public Outer Build()         {             return new Outer(this);         }     } } 

That ensures that the only way of building an instance of the outer class is via the builder.

I use a pattern very much like this in my C# port of Protocol Buffers.