6:
Reusing Classes
One of the most compelling features about Java is code reuse. But to be revolutionary, you’ve got to be able to do a lot more than copy code and change it.
That’s the approach used in procedural languages like C, and it hasn’t worked very well. Like everything in Java, the solution revolves around the class. You reuse code by creating new classes, but instead of creating them from scratch, you use existing classes that someone has already built and debugged.
The trick is to use the classes without soiling the existing code. In this chapter you’ll see two ways to accomplish this. The first is quite straightforward: you simply create objects of your existing class inside the new class. This is called composition, because the new class is composed of objects of existing classes. You’re simply reusing the functionality of the code, not its form.
The second approach is more subtle. It creates a new class as a type of an existing class. You literally take the form of the existing class and add code to it without modifying the existing class. This magical act is called inheritance, and the compiler does most of the work. Inheritance is one of the cornerstones of object-oriented programming, and has additional implications that will be explored in Chapter 7.
It turns out that much of the syntax and behavior are similar for both composition and inheritance (which makes sense because they are both ways of making new types from existing types). In this chapter, you’ll learn about these code reuse mechanisms.
Composition syntax
Until now, composition has been used quite frequently. You simply place object references inside new classes. For example, suppose you’d like an object that holds several String objects, a couple of primitives, and an object of another class. For the nonprimitive objects, you put references inside your new class, but you define the primitives directly:
//: c06:SprinklerSystem.java
// Composition for code reuse.
import com.bruceeckel.simpletest.*;
class WaterSource {
private String s;
WaterSource() {
System.out.println("WaterSource()");
s = new String("Constructed");
}
public String toString() { return s; }
}
public class SprinklerSystem {
private static Test monitor = new Test();
private String valve1, valve2, valve3, valve4;
private WaterSource source;
private int i;
private float f;
public String toString() {
return
"valve1 = " + valve1 + "\n" +
"valve2 = " + valve2 + "\n" +
"valve3 = " + valve3 + "\n" +
"valve4 = " + valve4 + "\n" +
"i = " + i + "\n" +
"f = " + f + "\n" +
"source = " + source;
}
public static void main(String[] args) {
SprinklerSystem sprinklers = new SprinklerSystem();
System.out.println(sprinklers);
monitor.expect(new String[] {
"valve1 = null",
"valve2 = null",
"valve3 = null",
"valve4 = null",
"i = 0",
"f = 0.0",
"source = null"
});
}
} ///:~
One of the methods defined in both classes is special: toString( ). You will learn later that every nonprimitive object has a toString( ) method, and it’s called in special situations when the compiler wants a String but it has an object. So in the expression in SprinklerSystem.toString( ):
"source = " + source;
the compiler sees you trying to add a String object ("source = ") to a WaterSource. Because you can only “add” a String to another String, it says “I’ll turn source into a String by calling toString( )!” After doing this it can combine the two Strings and pass the resulting String to System.out.println( ). Any time you want to allow this behavior with a class you create, you need only write a toString( ) method.
Primitives that are fields in a class are automatically initialized to zero, as noted in Chapter 2. But the object references are initialized to null, and if you try to call methods for any of them, you’ll get an exception. It’s actually good (and useful) that you can still print them out without throwing an exception.
It makes sense that the compiler doesn’t just create a default object for every reference, because that would incur unnecessary overhead in many cases. If you want the references initialized, you can do it:
- At the point the objects are defined. This means that they’ll always
be initialized before the constructor is called.
- In the constructor for that class.
- Right before you actually need to use the object. This is often called
lazy initialization. It can
reduce overhead in situations where object creation is expensive and the object
doesn’t need to be created every time.
//: c06:Bath.java
// Constructor initialization with composition.
import com.bruceeckel.simpletest.*;
class Soap {
private String s;
Soap() {
System.out.println("Soap()");
s = new String("Constructed");
}
public String toString() { return s; }
}
public class Bath {
private static Test monitor = new Test();
private String // Initializing at point of definition:
s1 = new String("Happy"),
s2 = "Happy",
s3, s4;
private Soap castille;
private int i;
private float toy;
public Bath() {
System.out.println("Inside Bath()");
s3 = new String("Joy");
i = 47;
toy = 3.14f;
castille = new Soap();
}
public String toString() {
if(s4 == null) // Delayed initialization:
s4 = new String("Joy");
return
"s1 = " + s1 + "\n" +
"s2 = " + s2 + "\n" +
"s3 = " + s3 + "\n" +
"s4 = " + s4 + "\n" +
"i = " + i + "\n" +
"toy = " + toy + "\n" +
"castille = " + castille;
}
public static void main(String[] args) {
Bath b = new Bath();
System.out.println(b);
monitor.expect(new String[] {
"Inside Bath()",
"Soap()",
"s1 = Happy",
"s2 = Happy",
"s3 = Joy",
"s4 = Joy",
"i = 47",
"toy = 3.14",
"castille = Constructed"
});
}
} ///:~
Note that in the Bath constructor, a statement is executed before any of the initializations take place. When you don’t initialize at the point of definition, there’s still no guarantee that you’ll perform any initialization before you send a message to an object reference—except for the inevitable run-time exception.
When toString( ) is called it fills in s4 so that all the fields are properly initialized by the time they are used.
