Static inner classes ... example?

[Ian Stone]

Can anyone give an example showing where defining a static
inner class (toplevel nested class) provides assistance ?
I understand the general principle of such a class I am just
drawing blanks currently as to how use of such a construct
might be exploited.

I can see how local anonymous inner classes are useful for
adapter code but static inners I just don't get (yet).

~ Ian

[Henrique Sousa]

There is a Campfire Story that solved that question for me, you might want to read it: getting in touch with your inner class. As for static inner classes, I don't see great use in them. Instance inner classes are good though. Best regards

[Ian Stone]

Thanks Henrique. I remember reading that campfire story alongside
some quite good sections in my mughal Java certification text before.
The campfire story, however, seems to reinforce my initial inclination
that static inner classes have more limited uses than true "instance"
inner classes.

~Ian

[Dirk Schreckmann]

I do not suggest this as a good way to design a system.

class Foo
{
  private static int count;
 
  static class Bar
  {
    static int getCount()
    {
      return count;
    }
  }
}

Note that the static inner class has access to the private static outer class member.

[Kathy Sierra]

Sun tells us that we're supposed to call them static "nested" classes instead of "inner", and it's a hard habit to break... but I'm just reminding y'all that if they're static, they're considered "nested" and not "inner". (I'm just the messenger )

Some people use static nested classes more for a naming scope, where non-staic nested (inner) classes are generally more useful, and used a lot in the Java API. I can't think of a time I've ever needed to use a static nested class, and I can't recall off the top of my head where I've seen a good example of one in the Java API, whereas inner classes are used in all sorts of things.

cheers,
Kathy

[Tony Morris]

Here is something I do often.
Suppose you have an interface:

interface I
{
    String reverse(String s);
}

Then your application will have only one implementation, however, if you expose that implementation as a public class, you run the risk of silly clients (clients are never silly!) using a reference of the concrete type. Then when it's time to perform a change (such as a feature or a fix), you have to support that concrete type for reverse compatibility. This is where the Factory Design Pattern becomes handy (there are other times).

Instead expose a factory method that clients use:

final class IFactory
{
    private IFactory(){}
 
    public static I createI()
    {
        return new IImpl();
    }
 
    private static final class IImpl implements I
    {
        public String reverse(String s)
        {
            // ***
        }
    }
}

*** Your implementation that you are free to change - independant of clients, provided the interface contract is met, which is usually stipulated in the javadoc.

This forces (silly) clients to use the interface type and they never get to see the implementation.

[ edited to move long unbroken comment line to outside of code body -ds ]
[ September 21, 2004: Message edited by: Dirk Schreckmann ]