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
    {


    }
}

The idea here is that all instances of 'Outer' would share access to the static state. Another way to do it might be to just let the Inner class be non-static and use a static instance of it:

public class Outer
{
    private static innerInstance = new Inner(); 

    private class Inner
    {


    }
}

Similar effect. What are the pros / cons or other considerations with this approach?

I must admit that I almost never use nested classes, whether static or not, but I am interested in this particular concept..

Wed

static classes are more efficient if u dont need to access members of outer class. Thus Node in Linkedlist.java is static. Look up on effective java – Odilo

Answer 1

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.

Organzine

Answer 2

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.

Fino

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.

Lucifer

Answer 4

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.

Callaghan

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.

Irremissible

Answer 6

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
    }
}

Disciple