So I'm still on the fence as to whether or not I should be using these or not.

I feel its an extreme violation of encapsulation, however I find that I am able to achieve some degree of encapsulation while gaining more flexibility in my code.

Previous Java/Swing projects I had used nested classes to some degree, However now I have moved into other projects in C# and I am avoid their use.

How do you feel about nested classes?

  • How exactly are nested classes a violation of encapsulation? If anything they are more encapsulated since they are 'encapsulated' inside another class, and can optionally be made private. Commented Jun 5, 2011 at 16:34

4 Answers 4


Well, too put it simply: nested classes do not violate encapsulation and in general, language features don't violate programming principles. Programmers violate programming principles.

Funnily enough, it is claimed nested classes increase encapsulation:

Increased encapsulation—Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be declared private. By hiding class B within class A, A's members can be declared private and B can access them. In addition, B itself can be hidden from the outside world.

There is some truth in that.

Usually B is a result of applying SRP to A. B itself however potentially violates many principles, especially, if all it does is fiddling round with A's private members :D

I think hidden classes can be useful. But there is a lot of potential for misuse.


We use nested classes all the time. In a lot of situations, business software/processes have nested business objects. We've all seen the example of an Order object which has a nested collection of OrderItems.

The bottom line is that it makes reading/writing the code easier and there's rarely a case where you would need your Order class and not need to know about OrderItems.


Personally, I feel like they should be avoided since they do couple your design in various (usually unfavorable) ways.

However, if your project has a set scope and encapsulating a class (such as a Node class or some sort of object that's used to traverse the datastructure of a specific class) then I don't see the harm.

In fact, I think for certain types of projects it makes the code (and the reasoning) more legible/ easy to understand. However, I think for most projects with extensibility in mind, it's a bad idea, because rarely will separating them cause you problems, but leaving them together may force you to decouple them in the future (which is wasted time).


(In C#) Generally I would avoid them, although it can depend exactly what purpose of the class is.

I would never use them for any kind of domain model class, that just makes no sense to me.

I used to use them for structuring data that is private in the outer class, but I've found that these almost always end up being needed externally later in the lifecycle of the project so I generally don't bother with this anymore.

The only time I use them now is for the odd little coding trick where using another small class makes implementing a particular class easier, or implementing an interface that is really just an event notification pattern (where the internal class will implement an interface and just passes control back the outer class).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.