Nested static classes are the simplest of the nested classes to write, understand, and use. Table 12-1 shows how to create a nested static class. You simply write the declaration of your class in the usual way, give it the modifier static, and put it inside a top-level class.
Table 12-1. Creating a nested static class
|
Java term |
Description |
Example code |
|---|---|---|
|
Nested static class |
class Top { |
A nested class that is declared “static.” This acts like a top-level class. |
You recall that static means “there is only one of these”. A static thing is not tied to an individual instance object. If you think about it, there is only one of any top-level class (though it might have a large number of instances). A static nested class acts exactly like a top-level class. The only differences are:
-
The full name of the nested static class includes the name of the class in which it is nested, e.g.
Top.MyNested. Instance declarations of the nested class outsideTopwould look like:Top.MyNested myObj = new Top.MyNested();
-
The nested static class has access to all the static methods and static data of the class it is nested in, even the private members.
If it helps, think of the “static” as having more to do with labelling the field of the top-level class, than with the nested class that is that field. Since the nested class is static, it does not have a “this” pointer to an instance of the enclosing class. Therefore, a nested static class has no direct access to the instance data in objects of its enclosing class. It can declare instances of itself or its outer class and access instance data that way.
This code shows how a static nested class can access instance data of the class it is nested within:
Imagine you are implementing a complicated class. Halfway through, you realize that you need a “helper” type with some utility methods. This helper type is self-contained enough that it can be a separate class from the complicated class. It can be used by other classes, not just the complicated class. But it is tied to the complicated class. Without the complicated class, there would be no reason for the helper class to exist.
Before nested classes, there wasn't a good solution to this, and you'd end up solving it by making the helper class a top-level class, and perhaps make some members of the complicated class more public than they should be. Today, you'd just make the helper class nested static, and put it inside the complicated class.
There's an example of a nested static class in the run-time in java.lang.Character. Simplifying it to omit irrelevant detail, it looks like the following:
public class Character {
/* more code */
public static class UnicodeBlock {
/* various methods, omitted */
}
The nested static class Character.UnicodeBlock stores the names of groups of characters (blocks) in the Unicode codeset. Often, there's a canonical name, like “Greek and Coptic” plus several aliases, all of which get stored. There are several dozen block names, corresponding to runs of adjacent characters: Cyrillic, Armenian, Hebrew, Arabic, and so on.
The class gives a way to associate names with Unicode code pages. You can see how that is tightly bound to class Character, but also useful outside it. Finally, it's all static final data; you don't need a unique but identical copy of all the code page names for every Character object. That would duplicate a large amount of unchanging data for every single char wrapper you have! The combination of requirements makes UnicodeBlock a perfect candidate for a static class nested inside java.lang.Character.