Question

I’m working on some MonoTouch code that I derived from one of the samples (this is not a MonoTouch specific question) and the sample code declares a private class inside another class. I’ve not seen private classes used much in c# and I’m at a loss as to when it might make sense. I can see how a class that is only referenced within another class could be declared private but isn’t this going to cause more grief than it’s worth? Doesn’t this break a number of the SOLID principles?

• Single Responsibility – broken?
• Open/Closed – broken?
• Liskoff Substitution – maybe ok?
• Interface Segregation – broken?
• Dependency Inversion – broken?

Right now I’m finding it confusing just trying to navigate the source because of the private class definition. I guess this could be mitigated somewhat by declaring a partial class to contain the private class and separating them into separate files that way but is this really a good approach?

Answer 1

Usually, nested types (either class or struct, including enumerations) are used for some kind of contextual data and/or behavior, which doesn’t have any sense without its context.

E.g., you could make nested types for some interop API, when you don’t want to provide access to that API from external code, or you’re using some kind of helper data container, which provides functionality, useful only for surrounding class.

So, even making these types internal can bring confusion to other developers (especially, where a single project is being edited by several people).

I don’t see, how SOLID is broken here – nesting the type is just a limiting of type scope. It is not an extending of functionality of the surrounding class.