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).
Joined: Apr 29, 2004
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
Henrique Sousa<br />SCJP 1.4<br /> <br />All men die, not all men really live - Braveheart, 1995
Joined: Sep 15, 2004
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.
Joined: Dec 10, 2001
I do not suggest this as a good way to design a system.Note that the static inner class has access to the private static outer class member.
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.
Joined: Sep 24, 2003
Here is something I do often. Suppose you have an interface:
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:
*** 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 ]