Private nested static class - Good or bad practice?

Question

Would it be considered a bad practice to nest a private static class inside of a non-static class?

public class Outer
{
    private static class Inner
    {
         


        

Answer 1

If the class is used in a multi-threaded application, you may need to control access to the static state via locking. That's a problem with static state whether privately nested or not.

Answer 2

Both approaches are entirely valid.

I wish developers would use private nested classes more often. In conjunction with c#'s partial keyword, it makes writing very complex classes much more maintainable. Imagine needing to build a class that has the complexity of a small application - much easier when you actually can build an entire private application, with classes that are totally internal to your complex outer class!

One very common case I've seen is enumerables - these can be quite complex, especially when you start building custom iterators that can be chained, like LINQ. Hiding the complexity inside the individual classes is the very definition of encapsulation.

Answer 3

Imagine needing to build a class that has the complexity of a small application ... with classes that are totally internal to your complex outer class

No, don't imagine it.

Just don't build a class that has the complexity of an application, even if a small application.

By doing so, you will actually increase the complexity.

Use separate classes, each having, ideally, a single responsibility.

That is the way to reduce complexity.

Answer 4

It's depend on what's Inner class do. If it's just a utility class static inner class is way to go.

public class Calculator
{
    private static class HexToDecUtils
    {
        // converter code here
    }
}

In other way, if Inner class is composite with other object, it should not be static class.

public class Car
{
    private class Engine
    {
        // your code here
    }
}

Answer 5

There's nothing wrong at all with this, and why should there be?

The scope is limited, so that only instances of the outer class have access to it, and it's a great place to put constants and other common functionality that is private to the functionality of the outer class, without having to instantiate it all the time.

I don't see this as anything but good practice.

Answer 6

Nothing wrong with it in principle, though if you're wanting a nested static class to help organize static state or methods, it could be a warning sign that the class is growing too large. Nested private classes have a lot of uses (internal data structures, private implementations of passed out private interfaces, etc.), but a static private class is really just a way to group things together.