Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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).
