Private inner classes in C# - why aren't they used more often ?

Question

I am relatively new to C# and each time I begun to work on a C# project (I only worked on nearly mature projects in C#) - I'm wondering why there is no inner classes.

Maybe I don't understand their goal. To me, inner classes -- at least private inner classes -- look a lot like "inner procedures" in Pascal / Modula-2 / Ada : they allow to break down a main class in smaller parts in order to ease the understanding.

Example : here is what is see most of the time :

public class ClassA
{
   public MethodA()
   {
      <some code>
      myObjectClassB.DoSomething(); // ClassB is only used by ClassA
      <some code>
   }
}

public class ClassB
{
   public DoSomething()
   {
   }
}

Since ClassB will be used (at least for a while) only by ClassA, my guess is that this code would be better expressed as follow :

   public class ClassA
   {
      public MethodA()
      {
         <some code>
         myObjectClassB.DoSomething(); // Class B is only used by ClassM
         <some code>
      }

      private class ClassB
      {
         public DoSomething()
         {
         }
      }
   }

I would be glad to ear you on that subject - Am I right ?

Thanks in advance !

Answer 1

For me personally I only create private inner classes if I need to create in-process collections of an object that may require methods on them.

Otherwise, it could cause confusion for other developers working on the project to actually find these classes, as they are not very clear as to where they are.

Answer 2

Nested classes (probably best to avoid the word "inner" as nested classes in C# are somewhat different to inner classes in Java) can indeed be very useful.

One pattern which hasn't been mentioned is the "better enum" pattern - which can be even more flexible than the one in Java:

public class MyCleverEnum
{
    public static readonly MyCleverEnum First = new FirstCleverEnum();
    public static readonly MyCleverEnum Second = new SecondCleverEnum();

    // Can only be called by this type *and nested types*
    private MyCleverEnum()
    {
    }

    public abstract void SomeMethod();
    public abstract void AnotherMethod();

    private class FirstCleverEnum : MyCleverEnum
    {
        public override void SomeMethod()
        {
             // First-specific behaviour here
        }

        public override void AnotherMethod()
        {
             // First-specific behaviour here
        }
    }

    private class SecondCleverEnum : MyCleverEnum
    {
        public override void SomeMethod()
        {
             // Second-specific behaviour here
        }

        public override void AnotherMethod()
        {
             // Second-specific behaviour here
        }
    }
}

We could do with some language support to do some of this automatically - and there are lots of options I haven't shown here, like not actually using a nested class for all of the values, or using the same nested class for multiple values, but giving them different constructor parameters. But basically, the fact that the nested class can call the private constructor gives a lot of power.

Answer 3

Jon, didn't you also use a nested class in order to create a thread-safe, lazy singleton ?

Answer 4

You should limit the responsibilities of each class so that each one stays simple, testable and reusable. Private inner classes go against that. They contribute to the complexity of the outer class, they are not testable and they are not reusable.

Answer 5

The Framework Design Guidelines has the best rules for using nested classes that I have found to date.

Here's a brief summary list

1) Do use nested types when the relationship between type and nested type is such the member-accessibility semantics are desired.

2) Do NOT use public nested types as a logical group construct

3) Avoid using publicly exposed nested types.

4) Do NOT use nested types if the type is likely to be referenced outside of the containing type.

5) Do NOT use nested types if they need to be instantiated by client code.

6) Do NOT define a nested type as a member of an interface.