"Public" nested classes or not

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

You might want to check out what Microsoft has to say on the topic. Basically it's a question of style I'd say.

Answer 2

I primarily use nested classes for fine-tuning access to the nested and/or the container class.

One thing to remember is that a nested class definition is basically a class member, and will have access to all the container's private variables.

You can also use this to control usage of a specific class.

Example:

public abstract class Outer
{
  protected class Inner
  {
  }
}

Now, in this case, the user (of your class) can only access the Inner class, iff* he implements Outer.

* Not a typo.

Answer 3

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 Builder()
        {
            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.

Answer 4

You can use namespaces to relate things that are... related.

For example:

namespace Diner
{
    public class Sandwich
    {
        public Sandwich(Filling filling) { }
    }

    public class Filling { }
}

The advantage of this over using classes as if they were namespaces is that you can optionally use using on the calling side to abbreviate things:

using Diner;

...

var sandwich = new Sandwich(new Filling());

If you use the Sandwich class as if it were a namespace for Filling, you have to use the full name Sandwich.Filling to refer to Filling.

And how are you going to sleep at night knowing that?