The Company class is the main class of our simplified payroll system:

An Employees encapsulate their names, salaries, and perhaps other personal data:

Here is the program output:

The gap between object creation time and object initialization time is bug-infested. Programmers should always strive to initialize all instance variables at object creation time with an appropriate constructor. Accordingly, Our Employee class is provided with a constructor that initializes name and salary.

An odd thing happens when we do this. The default constructor disappears. We can no longer create objects as we have in previous chapters:

When the programmer provides his own constructor, it seems the default (i.e., parameterless) constructor provided by Java disappears!

Even if the programmer doesn't explicitly call a default constructor, there are places where a default constructor is implicitly called. For example, if we introduce a subclass of Employee, the default constructor of the subclass will implicitly call the default constructor of the super class:

This isn't a big problem, because Java methods can be overloaded. Overloading means several methods can share the same name as long as their parameter lists are different.

Overloading applies to constructors, as well. We might use this fact to equip our Employee class with several different methods for initializing Employee objects:

We now have several options for creating an initializing employees:

Let's take a closer look at Employee.display():

Notice that this method refers to the employee's name and salary. But how does the method know which employee's name and salary are being referred to? We can give a superficial answer to this question by pointing out that calls to this method are always qualified by the employee in question:

But how is this information passed to the Employee.display() method? The answer is that this information is passed by an invisible or implicit Employee reference parameter:

We can understand the object qualifier that precedes calls to display() as an implicit argument with special syntax:

This mechanism might not be of much interest to programmers except that the implicit parameter is always called this and is always available inside of every method. This provides programmers with a convenient way of referring to the implicit argument. For example, suppose the IRS provides us with a method that reports employees with unusually large incomes, and requires us to call it each time such an employee object is constructed:

In this case we need to modify our Employee constructor. But where will we get the reference to the employee required by IRS.report()? This is the perfect opportunity to use the implicit parameter:

Suppose version 2.0 of the Payroll System now differentiates between executives and secretaries. We can introduce two new subclasses of Employee. This will save us from needing to duplicate complex HR-related code that might be in the Employee super class:

The Executive class extends the Employee super class by adding a boolean flag indicating if recreational use of the company jet on weekends is permitted. Two references to the executive's one or two personal secretaries are also added. In addition, the Executive class redefines the display() method inherited from the Employee base class:

The Secretary class extends the Employee super class by adding a field representing the secretary's typing speed in words per minute as well as a reference to the secretary's boss. In addition, the inherited display() method is redefined:

Let's first look at the Secretary constructor. Note that a secretary object inherits name and salary attributes from the Employee super class:

Unfortunately, these fields were declared private, not protected, in the Employee super class. This means that although every secretary has a name and salary, the secretary cannot directly access these attributes. In particular, the Secretary constructor can't initialize these fields using ordinary assignment statements:

Instead, the Secretary constructor must call the inherited Employee constructor to do the job. Every Java method has a second implicit parameter called super that is a reference to the object as an instance of the super class. I.e., something like:

A subclass constructor calls the desired super class constructor by placing the statement:

at the beginning of the constructor body. (Why not place:

at the beginning of the Secretary constructor?)

We see this phenomenon again in the redefined display method. The author of the Secretary class was apparently unhappy with the inherited display() method. Perhaps it was too generic. That's fine. Programmers can always redefine inherited methods. Programmers can even have their cake and eat it too. In the case of the Secretary display method, the inherited display method is called as a subroutine. To avoid making Secretary.display() recursive, the call to the inherited display method is qualified by the implicit super reference:

executing the code:

produces the output:

A type system for a language L is a set of primitive types together with a set of rules for constructing, comparing, and naming types, as well as rules for binding types to the expressions and values of L. For example, the primitive types of Java include int, float, char, and boolean. Arrays and classes are examples of constructed types.

Instances of a monomorphic or uniform type all have the same representation, while instances of a polymorphic or multi-form type can have a variety of representations. For example, a monomorphic Real type might represent all real numbers using the IEEE floating point standard representation, but a polymorphic Complex type might represent some complex numbers using polar coordinate representation (re^it) and others using rectangular coordinate representation (a+bi). A polymorphic type often can be viewed as a family of logically related subtypes.

All Java classes can be regarded as polymorphic types because instances of an extension can be treated as instances of the super class. For example, assume the following Shape class has been declared:

Assume Triangle, Rectangle, and Circle extend the Shape class. For example:

A reference to a Shape can actually refer to any instance of a Shape extension. For example:

Even though the shape[i] reference is of type Shape, the actual object shape[i] refers to is a specific type of shape. The Java compiler doesn't decide which variant of draw() should be called. Instead, this decision is left to the Java virtual machine, which uses the type of the object, not the type of the reference to determine which draw() variant should be called. For example, the following statement draws a circle, rectangle, and triangle in the graphical context g:

When it is time to upgrade or replace a chip in a computer, the old chip is simply popped out of the motherboard, and the new chip is plugged in. It doesn't matter if the new chip and old chip have the same manufacturer or the same internal circuitry, as long as they both "look" the same to the motherboard and the other chips in the computer. The same is true for car, television, and sewing machine components. Open architecture systems and "Pluggable" components allow customers to shop around for cheap, third-party generic components, or expensive, third-party high-performance components.

An interface is a collection of operator specifications. An operator specification may include a name, return type, parameter list, exception list, pre-conditions, and post-conditions. A class implements an interface if it implements the specified operators. A software component is an object that is known to its clients only through the interfaces it implements. Often, the client of a component is called a container. If software components are analogous to pluggable computer chips, then containers are analogous to the motherboards that contain and connect these chips. For example, an electronic commerce server might be designed as a container that contains and connects pluggable inventory, billing, and shipping components. A control panel might be implemented as a container that contains and connects pluggable calculator, calendar, and address book components. Java Beans and ActiveX controls are familiar examples of software components.

Modelers can represent interfaces in UML class diagrams using class icons stereotyped as interfaces. The relationship between an interface and a class that realizes or implements it is indicated by a dashed generalization arrow:

Notice that the container doesn't know the type of components it uses. It only knows that its components realize or implement the IComponent interface.

For example, imagine that a pilot flies an aircraft by remote control from inside of a windowless hangar. The pilot holds a controller with three controls labeled: TAKEOFF, FLY, and LAND, but he has no idea what type of aircraft the controller controls. It could be an airplane, a blimp, a helicopter, perhaps it's a space ship. Although this scenario may sound implausible, the pilot's situation is analogous to the situation any container faces: it controls components blindly through interfaces, without knowing the types of the components. Here is the corresponding class diagram:

Notice that all three realizations of the Aircraft interface support additional operations: airplanes can bank, helicopters can hover, and blimps can deflate. However, the pilot doesn't get to call these functions. The pilot only knows about the operations that are specifically declared in the Aircraft interface.

We can create new interfaces from existing interfaces using generalization. For example, the Airliner interface specializes the Aircraft and (Passenger) Carrier interfaces. The PassengerPlane class implements the Airliner interface, which means that it must implement the operations specified in the Aircraft and Carrier interfaces as well. Fortunately, it inherits implementations of the Aircraft interface from its Airplane super-class:

An interface is closely related to the idea of an abstract data type (ADT). In addition to the operator prototypes, an ADT might also specify the pre- and post-conditions of these operators. For example, the pre-condition for the Aircraft interface's takeoff() operator might be that the aircraft's altitude and airspeed are zero, and the post-condition might be that the aircraft's altitude and airspeed are greater than zero.

Java allows programmers to explicitly declare interfaces:

Notice that the interface declaration lacks private and protected members. There are no attributes, and no implementation information is provided.

A Pilot uses an Aircraft reference to control various types of aircraft:

Java also allows programmers to explicitly declare that a class implements an interface:

The following code shows how a pilot flies a blimp and a helicopter:

It is important to realize that Aircraft is an interface, not a class. As such, it cannot be instantiated:

Java also allows programmers to create new interfaces from existing interfaces by extension:

Although a Java class can only extend at most one class (multiple inheritance is forbidden in Java), a Java interface can extend multiple interfaces and a Java class can implement multiple interfaces. A Java class can even extend and implement at the same time:

Classes only inherit obligations from the interfaces they implement-obligations to implement the specified member functions. By contrast, an abstract class is a partially defined class. Classes derived from an abstract class inherit both features and obligations. For example, airplanes, blimps, and helicopters all have altitude and speed attributes. Why not declare these attributes, as well as their attending getter and setter functions, in the Aircraft base class:

Aircraft is no longer an interface, because it contains fields and implemented methods. But takeoff(), fly(), land() are abstract methods, which means users still won't be allowed to instantiate the Aircraft class.

Names of abstract classes and virtual functions are italicized in UML:

Let's return to the Simple payroll System described earlier. Recall that the Company class maintained an array of Employee references and a display method that traversed the array calling the display() method of each employee:

Also recall that Executive and Secretary were introduced as subclasses of Employee. Each class redefined the inherited display() method:

Let's alter the Company test harness so that Executives and Secretaries are hired instead of generic Employees:

Thanks to polymorphism, staff[i].display() calls the redefined Secretary and Executive display methods:

Let's add a method to each Employee subclass that returns a string describing the employee's position:

This method might be called by a countStaff() method in the Company class:

Unfortunately, the Company class won't compile, because there is no position() method in the Employee base class. Adding such a position raises what at first seems like a philosophical position: what is the position of a generic employee? We could simply add a method to the Employee super class that returns a bogus value:

Defining a method we hope never gets called is risky. Suppose a newly hired programmer is asked to extend the payroll system by adding a new subclass of Employee:

Unfortunately, the novice programmer forgets to add the required getPosition() method. There is no compiler or runtime error here. Instead, a logic error results when we attempt to find the number of galley slaves working for IBM:

Of course the right solution is to make getPosition() and abstract method in the Employee class:

Not providing an implementation of getPosition() in the GalleySlave class makes GalleySlave an abstract class. This results in a compile-time error when someone attempts to instantiate the GalleySlave class.

A devoted C programmer might offer the following objection at this point. Why bother with all of this fancy stuff. Why not simply add a type tag to the Employee class:

Any method that needs to process the staff array can use a multi-way conditional to determine the actual type of the staff member and then performs an explicit downcast:

Of course this solution doesn't make much sense in Java, where all methods are polymorphic by default, but C++ methods are monomorphic by default, so this type of a statement would make sense and would also improve efficiency, because the method called is determined in advance by the compiler rather than at runtime using a lookup table. But the problem is this: how many places in our clients code does this or a similar multi-way conditional exist? If we add a new subclass of Employee:

then we must locate every single multi-way conditional in the client's code and add a new clause.

If we miss one of these statements, then the client's code, which was tested bug-free yesterday, now has developed a bug!

Multi-way conditionals like the one above and like the notorious switch statement have become the symbol of the disease cured by the data-driven paradigm in much the same way as the goto statement became the symbol of the disease cured by the structured programming movement.

The data-driven paradigm is the pre-cursor to the object-oriented paradigm, which held that programmers should be in the business of specifying data rather than the flow of control. Thus, the flow of control that results from calling a polymorphic method like:

is determined by the object referenced by staff[i] rather than by a complex multiplexer inside of a single, monomorphic display method.

Assume we are developing a music framework called MFW. MFW is a horizontal framework that can be customized into various musical applications such as score editors, virtual recording studios, virtual instruments, expert systems for composers, and interfaces to computer controlled instruments such as synthesizers.

One part of MFW defines various ensembles of musical instruments: bands, orchestras, trios, quartets, etc. Unfortunately, the types of musical instruments will be defined much later in the various customizations of the framework. How can MFW form ensembles without knowing the identity of their constituent instruments? There are two solutions: make Instrument an abstract class in MFW, or make Instrument an MFW interface.

Although the specific types of instruments may be unknown, MFW can define an Instrument interface:

MFW is unable to implement the play() member function, so it is declared as a pure virtual function. Implementation class programmers will be required to provide implementations. Even though MFW couldn't implement play(), it can still call play(). For example, here is the MFW definition of Trio. Notice that Trio.play() calls the play() method of each instrument:

Suppose a programmer customizing MFW wishes to create and play trios consisting of different combinations of horns, harps, and drums. The first step is to create Instrument implementation classes. For example:

Here is how trios are created and played in the customization:

A container or collection is an object that stores other objects. Stacks and queues are familiar examples of containers. A heterogeneous container stores objects of different types. For example, an orchestra can be regarded as a container of different types of instruments:

Clients of the orchestra class can add a variety of instruments to orchestra instances:

Let's enhance MFW by adding an abstract Note class. Each note encapsulates a frequency and a duration:

Of course any musician will tell you that a note played on a guitar sounds quite different from the same note played on a horn. For this reason we have left the implementation of play() to MFW customizations; for example:

Now that we can talk about notes in MFW perhaps we can replace the Instrument interface by a concrete class:

But how can the Instrument class know what type of Notes to create? It would seem that creating an unknown type of object is more difficult than simply using an unknown type of object. How much memory should be allocated? How should the memory be initialized? Creating unknown objects is a common theme in programming. The various approaches to this problem are summarized by the Factory Method design pattern:

There are three variations of the pattern: virtual, smart, and template factory methods. Template factory methods are unavailable in Java, while smart factory methods will be discussed in Chapter ?.

An ordinary member function that creates and returns new objects is called a factory method. Although Java doesn't allow abstract constructors, factory methods can be abstract:

The obligation to implement the virtual factory method falls on the shoulders of extension classes:

One problem associated with virtual factory methods is that programmers must maintain two parallel inheritance hierarchies, one for factories, and one for products:

If a programmer creates a new type of note, he must remember to create the corresponding factory instrument that creates the note.

Java allows programmers to declare products to be inner classes of factories:

Declaring HornNote to be an inner class of Horn will discourage harps and drums from making horn notes:

Unlike C++, inner class Java objects are always created by outer class factories, but the syntax is weird:

Of course this technique for constructing notes fails if HornNote is declared as a private inner class. In this case clients are forced to use our makeNote() factory method.

Inner class objects can access the public, protected, and private fields and methods of their factories, but the syntax is weird:

Note: this isn't true if the inner class is declared static.

UML doesn't have a notation for inner classes; we can use a stereotyped association:

Classes can even be defined inside of a method:

We don't even have to name classes:

The general syntax is:

A functor (also called functional or function object) is an object that behaves like a method. A thunk (also called a promise) is a special type of functor. It's special because a thunk invocation can be frozen (delayed). Later, the frozen thunk can be thawed (forced), causing it to compute and return a value. The interesting thing is that a thunk remembers its freezing environment, which it uses to produce its value when thawed, even if the thawing environment is different. (Thunks are closely related to closures. A closure is a method that remembers its defining environment.)

Every thunk must implement a thaw() method that returns the computed value as an Object:

In this demo we want to convert the method ThunkDemo.foo() into a thunk. The foo() method simply computes the sum of two parameters and a local variable, but in reality, when called, foo() creates and returns an anonymous thunk that computes this value when thawed:

The test driver defines a couple of local variables, a = 3 and b = 4, then freezes a call to foo(a, b). Much later, the frozen call is thawed and produces the value 3 + 4 + 10 = 17, even though the values of a and b have been changed!

A memoization thunk caches its computed result so subsequent thaws don't need to re-compute anything. In this case Thunk becomes an abstract base class that provides the cache:

In this version of the test harness the thunk is thawed twice. The first time it computes the sum, the second time it simply returns the cached value:

Clearly this is an advantage if computing the value requires a lot of time.

Thunks are useful for representing streams. A stream is a potentially infinite sequence:

A stream is represented as a pair:

In the following demo, the tail of a stream representing the infinite sequence of integers always produces the next integer by incrementing the cache:

Here is a test harness that prints out the first 20 values of a potentially infinite stream, s:

Here's the program output:

Note: I'm not sure this example is very interesting, because one clould more easily accomplish the same thing in Java without using thunks.

Meta-classes and power-classes allow modelers to separate class from type. Instead of representing types implicitly as classes with no runtime existence, we can represent types as objects that instantiate meta or power classes.

For example, there are many types of aircraft: airplanes, blimps. helicopters, space ships, etc. We could represent this situation by introducing blimp, helicopter, and airplane as subclasses of an aircraft base class:

Alternatively, we could define a single Aircraft class and represent the different types of aircraft by different instances of an AircraftType power class. In this case it's common for instances of the power class to act as a factories that create instances of the type of objects they represent, the same way a class would provide a constructor for creating instances:

How can we insure that users won't bypass the factory and directly create aircraft? This can be done in Java by defining Aircraft to be a private inner class of AircraftType. We begin by introducing an aircraft interface:

Next, we define the AircraftType class with a private inner class and a factory method:

Here is how a client might create an aircraft:

Of course reflection is built into Java, so we can use the Java meta classes Class, Field, Method, etc. without writing extra code. For example, let's drop the getType() function from the IAircraft interface:

Assume Helicopter and SpaceShip implement this interface:

Here is how a client might build and takeoff in an aircraft without knowing the type of aircraft:

Sometimes the general sequence of tasks a function must perform is the same across a variety of applications, suggesting that the function belongs in a common framework. However, the tasks performed by the function are application-specific, suggesting the function belongs in the various framework customizations.

The generic algorithm design pattern solves this problem. Move the function into the framework and declare the application-specific tasks to be pure virtual functions in the framework. A function like this is called a generic algorithm or a template method.

Generic algorithms follow the inverted control structure sometimes called the Hollywood principle: "Don't call us, we'll call you."

Let's start with a trivial example to clarify the idea; more serious examples will come later. Suppose we want to add a symphony class to our music framework, MFW. Symphonies are usually divided into four movements, so playing a symphony is easy: play the first movement, then the second, then the third, finally the fourth. Of course the similarity between symphonies ends here. The particulars of each movement vary from one symphony to the next, and will have to be specified in various customizations of the framework. We can still add an abstract symphony base class to our framework, but play() will have to be a generic algorithm:

Framework customizers will have to subclass Symphony and implement the do-functions. For example:

Sometimes we want a class to have at most one instance. Why? Multiple instances might lead to confusion. For example, it would be confusing if an application had multiple user interfaces, simultaneously:

Multiple instances might lead to sharing problems. For example, changes to one instance of a company's budget must be reflected in other instances:

In some situations, multiple instances might simply be illogical:

The Singleton pattern solves this problem by making all constructors private. A public factory method is provided that allows users to create instances, but the factory method always returns pointers to the same hidden instance:

But doesn't this create a chicken and egg problem? How do we get the first instance of the class from which we can invoke the factory method:

This problem is solved by making the factory method static:

For example, let's apply the singleton pattern to the TheFifth class from the previous example:

Notice that the default constructor is private. The reference to the one and only instance is declared to be a private static variable.

Unsuspecting clients can call the factory method as many times as they want, but only one instances is ever created:

Any attempt to create instances using the new operator generates an error message:

The following class diagram shows many of the interfaces and implementation classes in the new Java Collections Framework (located in java.util):

Basically, a set is an unordered collection with no duplicate elements, while a list is an ordered collection with duplicate elements allowed. A map is a table or dictionary. Readers should consult the online Java Tutorial for more details.

Assume a many-to-one relationship between an Airplane class and a Fleet class:

We could provide a Java Fleet with a set of Airplane references:

A Java iterator is initialized so that it points to a "location" before the first element of its implicit argument, and provides methods for determining if there is a next element and for moving to and accessing the next element. For example, assume a fleet of three airplanes is created:

Here is how we would command each airplane in the fleet to takeoff:

The explicit downcast is necessary because Java collections are generic-- they hold Objects. Since every class implicitly extends the Java Object class, templates aren't needed.

Java's platform independence means, among other things, that the Java VM doesn't care how characters and numbers are represented on the host platform. This makes writing a simple interactive program with a console user interface (CUI) a bit of a challenge. Since this is a common task, we now present the first of two CUI-based application frameworks. The entire framework consists of two classes: Console and AppError.

As a demonstration of how to customize the framework, we present a simple calculator. Here are the basic commands:

The about command displays information about the framework and the customization:

Of course we can do arithmetic and small errors don't break the calculator:

The console framework provides two classes: Console and AppError. All application-specific errors discovered in the customization are handled by throwing an AppError. The Console class supplies a control loop, and overridable help(), about() , handle(), and execute() methods. In fact, execute() is abstract, which means Console is an abstract class and extensions are required to implement an execute method.