8: Interfaces & Inner Classes

Interfaces and inner classes provide more sophisticated ways to organize and control the objects in your system.

C++, for example, does not contain such mechanisms, although the clever programmer may simulate them. The fact that they exist in Java indicates that they were considered important enough to provide direct support through language keywords.

In Chapter 7, you learned about the abstract keyword, which allows you to create one or more methods in a class that have no definitions—you provide part of the interface without providing a corresponding implementation, which is created by inheritors. The interface keyword produces a completely abstract class, one that provides no implementation at all. You’ll learn that the interface is more than just an abstract class taken to the extreme, since it allows you to perform a variation on C++’s “multiple inheritance,” by creating a class that can be upcast to more than one base type.

At first, inner classes look like a simple code hiding mechanism: you place classes inside other classes. You’ll learn, however, that the inner class does more than that—it knows about and can communicate with the surrounding class—and that the kind of code you can write with inner classes is more elegant and clear, although it is a new concept to most so it takes some time to become comfortable with design using inner classes.

The interface keyword takes the abstract concept one step further. You could think of it as a “pure” abstract class. It allows the creator to establish the form for a class: method names, argument lists, and return types, but no method bodies. An interface can also contain fields, but these are implicitly static and final. An interface provides only a form, but no implementation.

An interface says: “This is what all classes that implement this particular interface will look like.” Thus, any code that uses a particular interface knows what methods might be called for that interface, and that’s all. So the interface is used to establish a “protocol” between classes. (Some object-oriented programming languages have a keyword called protocol to do the same thing.)

To create an interface, use the interface keyword instead of the class keyword. Like a class, you can add the public keyword before the interface keyword (but only if that interface is defined in a file of the same name) or leave it off to give “friendly” status so that it is only usable within the same package.

To make a class that conforms to a particular interface (or group of interfaces) use the implements keyword. You’re saying “The interface is what it looks like but now I’m going to say how it works.” Other than that, it looks like inheritance. The diagram for the instrument example shows this:

Once you’ve implemented an interface, that implementation becomes an ordinary class that can be extended in the regular way.

You can choose to explicitly declare the method declarations in an interface as public. But they are public even if you don’t say it. So when you implement an interface, the methods from the interface must be defined as public. Otherwise they would default to “friendly” and you’d be reducing the accessibility of a method during inheritance, which is not allowed by the Java compiler.

You can see this in the modified version of the Instrument example. Note that every method in the interface is strictly a declaration, which is the only thing the compiler allows. In addition, none of the methods in Instrument are declared as public, but they’re automatically public anyway:

The rest of the code works the same. It doesn’t matter if you are upcasting to a “regular” class called Instrument, an abstract class called Instrument, or to an interface called Instrument. The behavior is the same. In fact, you can see in the tune( ) method that there isn’t any evidence about whether Instrument is a “regular” class, an abstract class or an interface. This is the intent: Each approach gives the programmer different control over the way objects are created and used.

The interface isn’t simply a “more pure” form of abstract class. It has a higher purpose than that. Because an interface has no implementation at all—that is, there is no storage associated with an interface—there’s nothing to prevent many interfaces from being combined. This is valuable because there are times when you need to say “An x is an a and a b and a c.” In C++, this act of combining multiple class interfaces is called multiple inheritance, and it carries some rather sticky baggage because each class can have an implementation. In Java, you can perform the same act, but only one of the classes can have an implementation, so the problems seen in C++ do not occur with Java when combining multiple interfaces:

In a derived class, you aren’t forced to have a base class that is either an abstract or “concrete” (one with no abstract methods). If you do inherit from a non-interface, you can inherit from only one. All the rest of the base elements must be interfaces. You place all the interface names after the implements keyword and separate them with commas. You can have as many interfaces as you want—each one becomes an independent type that you can upcast to. The following example shows a concrete class combined with several interfaces to produce a new class:

You can see that Hero combines the concrete class ActionCharacter with the interfaces CanFight, CanSwim, and CanFly. When you combine a concrete class with interfaces this way, the concrete class must come first, then the interfaces. (The compiler gives an error otherwise.)

Note that the signature for fight( ) is the same in the interface CanFight and the class ActionCharacter, and that fight( ) is not provided with a definition in Hero. The rule for an interface is that you can inherit from it (as you will see shortly), but then you’ve got another interface. If you want to create an object of the new type, it must be a class with all definitions provided. Even though Hero does not explicitly provide a definition for fight( ), the definition comes along with ActionCharacter so it is automatically provided and it’s possible to create objects of Hero.

In class Adventure, you can see that there are four methods that take as arguments the various interfaces and the concrete class. When a Hero object is created, it can be passed to any of these methods, which means it is being upcast to each interface in turn. Because of the way interfaces are designed in Java, this works without a hitch and without any particular effort on the part of the programmer.

Keep in mind that the core reason for interfaces is shown in the above example: to be able to upcast to more than one base type. However, a second reason for using interfaces is the same as using an abstract base class: to prevent the client programmer from making an object of this class and to establish that it is only an interface. This brings up a question: Should you use an interface or an abstract class? An interface gives you the benefits of an abstract class and the benefits of an interface, so if it’s possible to create your base class without any method definitions or member variables you should always prefer interfaces to abstract classes. In fact, if you know something is going to be a base class, your first choice should be to make it an interface, and only if you’re forced to have method definitions or member variables should you change to an abstract class, or if necessary a concrete class.

You can encounter a small pitfall when implementing multiple interfaces. In the above example, both CanFight and ActionCharacter have an identical void fight( ) method. This is no problem because the method is identical in both cases, but what if it’s not? Here’s an example:

The difficulty occurs because overriding, implementation and overloading get unpleasantly mixed together, and overloaded functions cannot differ only by return type. When the last two lines are uncommented, the error messages say it all:

Using the same method names in different interfaces that are intended to be combined generally causes confusion in the readability of the code, as well. Strive to avoid it.

You can easily add new method declarations to an interface using inheritance, and you can also combine several interfaces into a new interface with inheritance. In both cases you get a new interface, as seen in this example:

DangerousMonster is a simple extension to Monster that produces a new interface. This is implemented in DragonZilla.

The syntax used in Vampire works only when inheriting interfaces. Normally, you can use extends with only a single class, but since an interface can be made from multiple other interfaces, extends can refer to multiple base interfaces when building a new interface. As you can see, the interface names are simply separated with commas.

Because any fields you put into an interface are automatically static and final, the interface is a convenient tool for creating groups of constant values, much as you would with an enum in C or C++. For example:

Notice the Java style of using all uppercase letters (with underscores to separate multiple words in a single identifier) for static finals that have constant initializers.

The fields in an interface are automatically public, so it’s unnecessary to specify that.

Now you can use the constants from outside the package by importing c08.* or c08.Months just as you would with any other package, and referencing the values with expressions like Months.JANUARY. Of course, what you get is just an int so there isn’t the extra type safety that C++’s enum has, but this (commonly used) technique is certainly an improvement over hard-coding numbers into your programs. (That approach is often referred to as using “magic numbers” and it produces very difficult-to-maintain code.)

If you do want extra type safety, you can build a class like this:[39]

The class is called Month2 since there’s already a Month in the standard Java library. It’s a final class with a private constructor so no one can inherit from it or make any instances of it. The only instances are the final static ones created in the class itself: JAN, FEB, MAR, etc. These objects are also used in the array month, which lets you choose months by number instead of by name. (Notice the extra JAN in the array to provide an offset by one, so that December is month 12.) In main( ) you can see the type safety: m is a Month2 object so it can be assigned only to a Month2. The previous example Months.java provided only int values, so an int variable intended to represent a month could actually be given any integer value, which wasn’t too safe.

This approach also allows you to use == or equals( ) interchangeably, as shown at the end of main( ).

Fields defined in interfaces are automatically static and final. These cannot be “blank finals,” but they can be initialized with non-constant expressions. For example:

Since the fields are static, they are initialized when the class is first loaded, which happens when any of the fields are accessed for the first time. Here’s a simple test:

The fields, of course, are not part of the interface but instead are stored in the static storage area for that interface.

It’s possible to place a class definition within another class definition. This is called an inner class. The inner class is a useful feature because it allows you to group classes that logically belong together and to control the visibility of one within the other. However, it’s important to understand that inner classes are distinctly different from composition.

Often, while you’re learning about them, the need for inner classes isn’t immediately obvious. At the end of this section, after all of the syntax and semantics of inner classes have been described, you’ll find examples that should make clear the benefits of inner classes.

You create an inner class just as you’d expect: by placing the class definition inside a surrounding class:

The inner classes, when used inside ship( ), look just like the use of any other classes. Here, the only practical difference is that the names are nested within Parcel1. You’ll see in a while that this isn’t the only difference.

More typically, an outer class will have a method that returns a reference to an inner class, like this:

If you want to make an object of the inner class anywhere except from within a non-static method of the outer class, you must specify the type of that object as OuterClassName.InnerClassName, as seen in main( ).

So far, inner classes don’t seem that dramatic. After all, if it’s hiding you’re after, Java already has a perfectly good hiding mechanism—just allow the class to be “friendly” (visible only within a package) rather than creating it as an inner class.

However, inner classes really come into their own when you start upcasting to a base class, and in particular to an interface. (The effect of producing an interface reference from an object that implements it is essentially the same as upcasting to a base class.) That’s because the inner class—the implementation of the interface—can then be completely unseen and unavailable to anyone, which is convenient for hiding the implementation. All you get back is a reference to the base class or the interface.

First, the common interfaces will be defined in their own files so they can be used in all the examples:

Now Contents and Destination represent interfaces available to the client programmer. (The interface, remember, automatically makes all of its members public.)

When you get back a reference to the base class or the interface, it’s possible that you can’t even find out the exact type, as shown here:

Note: since main( ) is in Test, when you want to run this program you don’t execute Parcel3, but instead:

In the example, main( ) must be in a separate class in order to demonstrate the privateness of the inner class PContents.

In Parcel3, something new has been added: the inner class PContents is private so no one but Parcel3 can access it. PDestination is protected, so no one but Parcel3, classes in the Parcel3 package (since protected also gives package access—that is, protected is also “friendly”), and the inheritors of Parcel3 can access PDestination. This means that the client programmer has restricted knowledge and access to these members. In fact, you can’t even downcast to a private inner class (or a protected inner class unless you’re an inheritor), because you can’t access the name, as you can see in class Test. Thus, the private inner class provides a way for the class designer to completely prevent any type-coding dependencies and to completely hide details about implementation. In addition, extension of an interface is useless from the client programmer’s perspective since the client programmer cannot access any additional methods that aren’t part of the public interface class. This also provides an opportunity for the Java compiler to generate more efficient code.

Normal (non-inner) classes cannot be made private or protected—only public or “friendly.”

What you’ve seen so far encompasses the typical use for inner classes. In general, the code that you’ll write and read involving inner classes will be “plain” inner classes that are simple and easy to understand. However, the design for inner classes is quite complete and there are a number of other, more obscure, ways that you can use them if you choose: inner classes can be created within a method or even an arbitrary scope. There are two reasons for doing this:

In the following examples, the previous code will be modified to use:

Although it’s an ordinary class with an implementation, Wrapping is also being used as a common “interface” to its derived classes:

You’ll notice above that Wrapping has a constructor that requires an argument, to make things a bit more interesting.

The first example shows the creation of an entire class within the scope of a method (instead of the scope of another class):

The class PDestination is part of dest( ) rather than being part of Parcel4. (Also notice that you could use the class identifier PDestination for an inner class inside each class in the same subdirectory without a name clash.) Therefore, PDestination cannot be accessed outside of dest( ). Notice the upcasting that occurs in the return statement—nothing comes out of dest( ) except a reference to Destination, the base class. Of course, the fact that the name of the class PDestination is placed inside dest( ) doesn’t mean that PDestination is not a valid object once dest( ) returns.

The next example shows how you can nest an inner class within any arbitrary scope:

The class TrackingSlip is nested inside the scope of an if statement. This does not mean that the class is conditionally created—it gets compiled along with everything else. However, it’s not available outside the scope in which it is defined. Other than that, it looks just like an ordinary class.

The next example looks a little strange:

The cont( ) method combines the creation of the return value with the definition of the class that represents that return value! In addition, the class is anonymous—it has no name. To make matters a bit worse, it looks like you’re starting out to create a Contents object:

but then, before you get to the semicolon, you say, “But wait, I think I’ll slip in a class definition”:

What this strange syntax means is “create an object of an anonymous class that’s inherited from Contents.” The reference returned by the new expression is automatically upcast to a Contents reference. The anonymous inner class syntax is a shorthand for:

In the anonymous inner class, Contents is created using a default constructor. The following code shows what to do if your base class needs a constructor with an argument:

That is, you simply pass the appropriate argument to the base-class constructor, seen here as the x passed in new Wrapping(x). An anonymous class cannot have a constructor where you would normally call super( ).

In both of the previous examples, the semicolon doesn’t mark the end of the class body (as it does in C++). Instead, it marks the end of the expression that happens to contain the anonymous class. Thus, it’s identical to the use of the semicolon everywhere else.

What happens if you need to perform some kind of initialization for an object of an anonymous inner class? Since it’s anonymous, there’s no name to give the constructor—so you can’t have a constructor. You can, however, perform initialization at the point of definition of your fields:

If you’re defining an anonymous inner class and want to use an object that’s defined outside the anonymous inner class, the compiler requires that the outside object be final. This is why the argument to dest( ) is final. If you forget, you’ll get a compile-time error message.

As long as you’re simply assigning a field, the above approach is fine. But what if you need to perform some constructor-like activity? With instance initialization, you can, in effect, create a constructor for an anonymous inner class:

Inside the instance initializer you can see code that couldn’t be executed as part of a field initializer (that is, the if statement). So in effect, an instance initializer is the constructor for an anonymous inner class. Of course, it’s limited; you can’t overload instance initializers so you can have only one of these constructors.

So far, it appears that inner classes are just a name-hiding and code-organization scheme, which is helpful but not totally compelling. However, there’s another twist. When you create an inner class, an object of that inner class has a link to the enclosing object that made it, and so it can access the members of that enclosing object—without any special qualifications. In addition, inner classes have access rights to all the elements in the enclosing class[40]. The following example demonstrates this:

The Sequence is simply a fixed-sized array of Object with a class wrapped around it. You call add( ) to add a new Object to the end of the sequence (if there’s room left). To fetch each of the objects in a Sequence, there’s an interface called Selector, which allows you to see if you’re at the end( ), to look at the current( ) Object, and to move to the next( ) Object in the Sequence. Because Selector is an interface, many other classes can implement the interface in their own ways, and many methods can take the interface as an argument, in order to create generic code.

Here, the SSelector is a private class that provides Selector functionality. In main( ), you can see the creation of a Sequence, followed by the addition of a number of String objects. Then, a Selector is produced with a call to getSelector( ) and this is used to move through the Sequence and select each item.

At first, the creation of SSelector looks like just another inner class. But examine it closely. Note that each of the methods end( ), current( ), and next( ) refer to obs, which is a reference that isn’t part of SSelector, but is instead a private field in the enclosing class. However, the inner class can access methods and fields from the enclosing class as if they owned them. This turns out to be very convenient, as you can see in the above example.

So an inner class has automatic access to the members of the enclosing class. How can this happen? The inner class must keep a reference to the particular object of the enclosing class that was responsible for creating it. Then when you refer to a member of the enclosing class, that (hidden) reference is used to select that member. Fortunately, the compiler takes care of all these details for you, but you can also understand now that an object of an inner class can be created only in association with an object of the enclosing class. Construction of the inner class object requires the reference to the object of the enclosing class, and the compiler will complain if it cannot access that reference. Most of the time this occurs without any intervention on the part of the programmer.

If you don’t need a connection between the inner class object and the outer class object, then you can make the inner class static. To understand the meaning of static when applied to inner classes, you must remember that the object of an ordinary inner class implicitly keeps a reference to the object of the enclosing class that created it. This is not true, however, when you say an inner class is static. A static inner class means:

static inner classes are different than non-static inner classes in another way, as well. Fields and methods in non-static inner classes can only be at the outer level of a class, so non-static inner classes cannot have static data, static fields, or static inner classes. However, static inner classes can have all of these:

In main( ), no object of Parcel10 is necessary; instead you use the normal syntax for selecting a static member to call the methods that return references to Contents and Destination.

As you will see shortly, in an ordinary (non-static) inner class, the link to the outer class object is achieved with a special this reference. A static inner class does not have this special this reference, which makes it analogous to a static method.

Normally you can’t put any code inside an interface, but a static inner class can be part of an interface. Since the class is static it doesn’t violate the rules for interfaces—the static inner class is only placed inside the namespace of the interface:

Earlier in this book I suggested putting a main( ) in every class to act as a test bed for that class. One drawback to this is the amount of extra compiled code you must carry around. If this is a problem, you can use a static inner class to hold your test code:

This generates a separate class called TestBed$Tester (to run the program you say java TestBed$Tester). You can use this class for testing, but you don’t need to include it in your shipping product.

If you need to produce the reference to the outer class object, you name the outer class followed by a dot and this. For example, in the class Sequence.SSelector, any of its methods can produce the stored reference to the outer class Sequence by saying Sequence.this. The resulting reference is automatically the correct type. (This is known and checked at compile-time, so there is no run-time overhead.)

Sometimes you want to tell some other object to create an object of one of its inner classes. To do this you must provide a reference to the other outer class object in the new expression, like this:

To create an object of the inner class directly, you don’t follow the same form and refer to the outer class name Parcel11 as you might expect, but instead you must use an object of the outer class to make an object of the inner class:

Thus, it’s not possible to create an object of the inner class unless you already have an object of the outer class. This is because the object of the inner class is quietly connected to the object of the outer class that it was made from. However, if you make a static inner class, then it doesn’t need a reference to the outer class object.

Because the inner class constructor must attach to a reference of the enclosing class object, things are slightly complicated when you inherit from an inner class. The problem is that the “secret” reference to the enclosing class object must be initialized, and yet in the derived class there’s no longer a default object to attach to. The answer is to use a syntax provided to make the association explicit:

You can see that InheritInner is extending only the inner class, not the outer one. But when it comes time to create a constructor, the default one is no good and you can’t just pass a reference to an enclosing object. In addition, you must use the syntax

inside the constructor. This provides the necessary reference and the program will then compile.

What happens when you create an inner class, then inherit from the enclosing class and redefine the inner class? That is, is it possible to override an inner class? This seems like it would be a powerful concept, but “overriding” an inner class as if it were another method of the outer class doesn’t really do anything:

The default constructor is synthesized automatically by the compiler, and this calls the base-class default constructor. You might think that since a BigEgg is being created, the “overridden” version of Yolk would be used, but this is not the case. The output is:

This example simply shows that there isn’t any extra inner class magic going on when you inherit from the outer class. The two inner classes are completely separate entities, each in their own namespace. However, it’s still possible to explicitly inherit from the inner class:

Now BigEgg2.Yolk explicitly extends Egg2.Yolk and overrides its methods. The method insertYolk( ) allows BigEgg2 to upcast one of its own Yolk objects into the y reference in Egg2, so when g( ) calls y.f( ) the overridden version of f( ) is used. The output is:

The second call to Egg2.Yolk( ) is the base-class constructor call of the BigEgg2.Yolk constructor. You can see that the overridden version of f( ) is used when g( ) is called.

Since every class produces a .class file that holds all the information about how to create objects of this type (this information produces a “meta-class” called the Class object), you might guess that inner classes must also produce .class files to contain the information for their Class objects. The names of these files/classes have a strict formula: the name of the enclosing class, followed by a ‘$’, followed by the name of the inner class. For example, the .class files created by InheritInner.java include:

If inner classes are anonymous, the compiler simply starts generating numbers as inner class identifiers. If inner classes are nested within inner classes, their names are simply appended after a ‘$’ and the outer class identifier(s).

Although this scheme of generating internal names is simple and straightforward, it’s also robust and handles most situations[41]. Since it is the standard naming scheme for Java, the generated files are automatically platform-independent. (Note that the Java compiler is changing your inner classes in all sorts of other ways in order to make them work.)

At this point you’ve seen a lot of syntax and semantics describing the way inner classes work, but this doesn’t answer the question of why they exist. Why did Sun go to so much trouble to add this fundamental language feature?

Typically, the inner class inherits from a class or implements an interface, and the code in the inner class manipulates the outer class object that it was created within. So you could say that an inner class provides a kind of window into the outer class.

A question that cuts to the heart of inner classes is this: if I just need a reference to an interface, why don’t I just make the outer class implement that interface? The answer is “If that’s all you need, then that’s how you should do it.” So what is it that distinguishes an inner class implementing an interface from an outer class implementing the same interface? The answer is that you can’t always have the convenience of interfaces—sometimes you’re working with implementations. So the most compelling reason for inner classes is:

Each inner class can independently inherit from an implementation. Thus, the inner class is not limited by whether the outer class is already inheriting from an implementation.

Without the ability that inner classes provide to inherit—in effect –from more than one concrete or abstract class, some design and programming problems would be intractable. So one way to look at the inner class is as the completion of the solution of the multiple-inheritance problem. Interfaces solve part of the problem, but inner classes effectively allow “multiple implementation inheritance.” That is, inner classes effectively allow you to inherit from more than one non-interface.

To see this in more detail, consider a situation where you have two interfaces that must somehow be implemented within a class. Because of the flexibility of interfaces, you have two choices: a single class or an inner class:

Of course, this assumes that the structure of your code makes logical sense either way. However, you’ll ordinarily have some kind of guidance from the nature of the problem about whether to use a single class or an inner class. But without any other constraints, in the above example the approach you take doesn’t really make much difference from an implementation standpoint. Both of them work.

However, if you have abstract or concrete classes instead of interfaces, you are suddenly limited to using inner classes if your class must somehow implement both of the others:

If you didn’t need to solve the “multiple implementation inheritance” problem, you could conceivably code around everything else without the need for inner classes. But with inner classes you have these additional features:

As an example, if Sequence.java did not use inner classes, you’d have to say “a Sequence is a Selector,” and you’d only be able to have one Selector in existence for a particular Sequence. Also, you can have a second method, getRSelector( ), that produces a Selector that moves backwards through the sequence. This kind of flexibility is only available with inner classes.

A closure is a callable object that retains information from the scope in which it was created. From this definition, you can see that an inner class is a object-oriented closure, because it doesn’t just contain each piece of information from the outer class object (“the scope in which it was created”), but it automatically holds a reference back to the whole outer class object, where it has permission to manipulate all the members, even private ones.

One of the most compelling arguments made to include some kind of pointer mechanism in Java was to allow callbacks. With a callback, some other object is given a piece of information that allows it to call back into the originating object at some later point. This is a very powerful concept, as you will see in Chapters 13 and 16. If a callback is implemented using a pointer, however, you must rely on the programmer to behave and not misuse the pointer. As you’ve seen by now, Java tends to be more careful than that so pointers were not included in the language.

The closure provided by the inner class is a perfect solution; more flexible and far safer than a pointer. Here’s a simple example:

Notice that everything except getCallbackReference( ) in Callee is private. To allow any connection to the outside world, the interface Incrementable is essential. Here you can see how interfaces allow for a complete separation of interface from implementation.

The inner class Closure simply implements Incrementable to provide a hook back into Callee—but a safe hook. Whoever gets the Incrementable reference can, of course, only call increment( ) and has no other abilities (unlike a pointer, which would allow you to run wild).

Caller takes an Incrementable reference in its constructor (although the capturing of the callback reference could happen at any time) and then, sometime latter, uses the reference to “call back” into the Callee class.

The value of the callback is in its flexibility—you can dynamically decide what functions will be called at run-time. The benefit of this will become more evident in Chapter 13, where callbacks are used everywhere to implement graphical user interface (GUI) functionality.

A more concrete example of the use of inner classes can be found in something that I will refer to here as a control framework.

An application framework is a class or a set of classes that’s designed to solve a particular type of problem. To apply an application framework, you inherit from one or more classes and override some of the methods. The code you write in the overridden methods customizes the general solution provided by that application framework, in order to solve your specific problem. The control framework is a particular type of application framework dominated by the need to respond to events; a system that primarily responds to events is called an event-driven system. One of the most important problems in application programming is the graphical user interface (GUI), which is almost entirely event-driven. As you will see in Chapter 13, the Java Swing library is a control framework that elegantly solves the GUI problem and that heavily uses inner classes.

To see how inner classes allow the simple creation and use of control frameworks, consider a control framework whose job is to execute events whenever those events are “ready.” Although “ready” could mean anything, in this case the default will be based on clock time. What follows is a control framework that contains no specific information about what it’s controlling. First, here is the interface that describes any control event. It’s an abstract class instead of an actual interface because the default behavior is to perform the control based on time, so some of the implementation can be included here:

The constructor simply captures the time when you want the Event to run, while ready( ) tells you when it’s time to run it. Of course, ready( ) could be overridden in a derived class to base the Event on something other than time.

action( ) is the method that’s called when the Event is ready( ), and description( ) gives textual information about the Event.

The following file contains the actual control framework that manages and fires events. The first class is really just a “helper” class whose job is to hold Event objects. You can replace it with any appropriate container, and in Chapter 9 you’ll discover other containers that will do the trick without requiring you to write this extra code:

EventSet arbitrarily holds 100 Events. (If a “real” container from Chapter 9 is used here you don’t need to worry about its maximum size, since it will resize itself). The index is used to keep track of the next available space, and next is used when you’re looking for the next Event in the list, to see whether you’ve looped around. This is important during a call to getNext( ), because Event objects are removed from the list (using removeCurrent( )) once they’re run, so getNext( ) will encounter holes in the list as it moves through it.

Note that removeCurrent( ) doesn’t just set some flag indicating that the object is no longer in use. Instead, it sets the reference to null. This is important because if the garbage collector sees a reference that’s still in use then it can’t clean up the object. If you think your references might hang around (as they would here), then it’s a good idea to set them to null to give the garbage collector permission to clean them up.

Controller is where the actual work goes on. It uses an EventSet to hold its Event objects, and addEvent( ) allows you to add new events to this list. But the important method is run( ). This method loops through the EventSet, hunting for an Event object that’s ready( ) to run. For each one it finds ready( ), it calls the action( ) method, prints out the description( ), and then removes the Event from the list.

Note that so far in this design you know nothing about exactly what an Event does. And this is the crux of the design; how it “separates the things that change from the things that stay the same.” Or, to use my term, the “vector of change” is the different actions of the various kinds of Event objects, and you express different actions by creating different Event subclasses.

This is where inner classes come into play. They allow two things:

Consider a particular implementation of the control framework designed to control greenhouse functions[42]. Each action is entirely different: turning lights, water, and thermostats on and off, ringing bells, and restarting the system. But the control framework is designed to easily isolate this different code. Inner classes allow you to have multiple derived versions of the same base class, Event, within a single class. For each type of action you inherit a new Event inner class, and write the control code inside of action( ).

As is typical with an application framework, the class GreenhouseControls is inherited from Controller:

Note that light, water, thermostat, and rings all belong to the outer class GreenhouseControls, and yet the inner classes can access those fields without qualification or special permission. Also, most of the action( ) methods involve some sort of hardware control, which would most likely involve calls to non-Java code.

Most of the Event classes look similar, but Bell and Restart are special. Bell rings, and if it hasn’t yet rung enough times it adds a new Bell object to the event list, so it will ring again later. Notice how inner classes almost look like multiple inheritance: Bell has all the methods of Event and it also appears to have all the methods of the outer class GreenhouseControls.

Restart is responsible for initializing the system, so it adds all the appropriate events. Of course, a more flexible way to accomplish this is to avoid hard-coding the events and instead read them from a file. (An exercise in Chapter 11 asks you to modify this example to do just that.) Since Restart( ) is just another Event object, you can also add a Restart object within Restart.action( ) so that the system regularly restarts itself. And all you need to do in main( ) is create a GreenhouseControls object and add a Restart object to get it going.

Interfaces and inner classes are more sophisticated concepts than what you’ll find in many OOP languages. For example, there’s nothing like them in C++. Together, they solve the same problem that C++ attempts to solve with its multiple inheritance (MI) feature. However, MI in C++ turns out to be rather difficult to use, while Java interfaces and inner classes are, by comparison, much more accessible.

Although the features themselves are reasonably straightforward, the use of these features is a design issue, much the same as polymorphism. Over time, you’ll become better at recognizing situations where you should use an interface, or an inner class, or both. But at this point in this book you should at least be comfortable with the syntax and semantics. As you see these language features in use you’ll eventually internalize them.