C#, is it okay to use nested classes for logical structure?

Question

I am having a bit of a debate about the use of nested classes. The situation is that a class name makes sense to be repeated in two or more places, and while there is moderate similarity between each of the different instances, they are generally different. The nested classes are not often (if at all) needed beyond the scope of their parent class.

So then, rather than just coming up with three different class names, this seems to make more sense to me.

class A {
   class B {
}

class M {
   class B {
   }
}

class Q {
   class B {
   }
}

The obvious problem with that is not functionality, but rather consistency/repetition. I was wondering if other developers have ever struggled with the same thing, and what some of the opinions were.

Answer 1

The .net Design Guide advises against it:

• "Do not use public nested types as a logical grouping construct; use namespaces for this."
• "Avoid publicly exposed nested types. The only exception to this is when variables of the nested type need to be declared in rare scenarios such as subclassing or other advanced customization scenarios."

That's also what the base class library does: In the System.Web.UI namespace, you have DataGridItem, DataListItem, ListViewItem, MenuItem, RepeaterItem, etc. All of these could be called Item and nested inside DataGrid, DataList, etc. However, this would violate the two principles outlined above.

Answer 2

It looks okay when your classes are small. Once they get bloated, you really start thinking about moving them in separate files.

More to your point, if you want to use both A.B and M.B in the same code you have to always type A.B and M.B, which can be a pain.

Answer 3

If class B has any similarities between each inner class instance, would it make sense for you to abstract the similarities of B to a base class that exists alongside A, M, and Q? (I think so.) Then your inner classes, while they may have the same name, would be a little cleaner.

With that said, this type of structure can be seen for things like Metadata in an MVC application. In that instance you'd have something like:

[MetadataType(typeof(A.Metadata))]
class A
{
    protected class Metadata
    {
        ...
    }
}

[MetadataType(typeof(B.Metadata))]
class B
{
    protected class Metadata
    {
        ...
    }
}

In these case the inner classes each serve the same purpose but their implementations vary with each parent class. Also, with the Metadata definitions here, it makes a lot of sense to keep a class that helps describe its parent as an inner class. If there's any chance you might want to re-use the inner classes elsewhere then I would move them outside of their parents.

I think it's a little atypical to see this in practice otherwise. I'm sure there are good examples, but I bet there are more bad examples of this type of pattern.