A couple of use cases for nested static classes in Java

Photo by Vignesh Jayaprakash on Unsplash

Whenever you can use an anonymous class, you can use a named nested static class instead. But that only makes sense if you need to instantiate the class from two or more places.

That’s probably not going to be the case with an iterator, but it’s likely to be the case with nodes in a singly- or doubly-linked list.

Nodes in a linked list

Instead of a backing array to hold the elements of a list, like ArrayList, a linked list has linked nodes to hold the elements.

Then we can use a private nested static class to represent each individual node in a linked list.

In the case of a singly-linked list, each node needs to hold only two things: the element and a pointer to the next node or the previous node, or a null pointer if it’s the last or first element in the list (depending on whether the links are forward- or backward-pointing).

A diagram showing a linked list with four elements.

One of the advantages of linked lists is that insertions and removals to and from the middle of the list are very easy. There’s no need to move elements around in a backing array.

Diagram showing the insertion of an element into a linked list.

In either direction.

Diagram showing the removal of an element from a linked list.

Linked lists also have their drawbacks, but that’s outside the scope of this article. The important thing is that the nodes of a linked list can be represented by a specialized class that is nested within the linked list class.

Here’s a rough draft for SinglyLinkedList<E>:

Since Node<E> has no need to access the enclosing class this, it can be declared as a nested static class rather than an inner class.

Implementing class nested in a test class

Another use case is one that I thank Apache NetBeans for: using a static nested class nested inside the test class for an abstract class under test.

As I try to be more thorough about test-driven development (TDD), I realized that in most cases abstract classes need to be tested. The first time I thought about that, I decided to give it a try in NetBeans.

If you have NetBeans generate a test class for an abstract class, it will probably include an “Impl” class nested in the test class. For example, if SomeClass is abstract and has a constructor that requires one or more parameters, NetBeans will include SomeClassImpl nested in SomeClassTest.

However, NetBeans will not mark such an Impl class as static nor remind you that it can be static. But maybe you can chalk this up to NetBeans not being as “opinionated” as Eclipse or IntelliJ IDEA — that last one will definitely let you know when a nested class can be static.

For example, given this abstract class,

NetBeans will generate for you something like this:

package postal;
// JUnit imports go here
public class PostalCodeTest {
    // Test stub for getCountry()
    private class PostalCodeImpl extends PostalCode {
        
        @Override
        public String toString() {
            return "ImplPostal " + this.postalCodeNumber;
        }
        PostalCodeImpl(int code) {
            super(code, Locale.US);
        }
        
    }
}

As a matter of good form you add “static” to the PostalCodeImpl declaration. I like this idea so much I use it in my IntelliJ projects as well, which is how I found out that I was missing the static declaration for this particular use case.