Reference types and Java classes

The code in Listing 17-1 involves a few simple values: unitPrice, quantity, and taxable. So here’s the main point of this chapter: By combining several simple values, you can get a single, more useful value. That’s the way it works. You take some of Java’s primitive types, whip them together to make a primitive type stew, and what do you get? You get a more useful type called a reference type. Listing 17-2 has an example.

LISTING 17-2 What It Means to Be a Purchase

class Purchase {
double unitPrice;
int quantity;
boolean taxable;
}

The code in Listing 17-2 has no main method, so Eclipse can compile the code, but you can’t run it. When you choose Run ⇒   Run As on Eclipse’s main menu, the resulting context menu has no Java Application entry. You can click the tiny Run As button in Eclipse’s toolbar and then select Java Application. But then you get the message box shown in Figure 17-2. Because Listing 17-2 has no main method, there’s no place to start the executing. (In fact, the code in Listing 17-2 has no statements at all. There’s nothing to execute.)

Using a newly defined class

To do something useful with the code in Listing 17-2, you need a main method. You can put the main method in a separate file. Listing 17-3 shows you such a file.

LISTING 17-3 Using Your Purchase Class

import java.util.Scanner;

class ProcessPurchase {

public static void main(String[] args) {
Scanner keyboard = new Scanner(System.in);
Purchase onePurchase = new Purchase();

System.out.print("Unit price: ");
onePurchase.unitPrice = keyboard.nextDouble();
System.out.print("Quantity: ");
onePurchase.quantity = keyboard.nextInt();
System.out.print("Taxable? (true/false) ");
onePurchase.taxable = keyboard.nextBoolean();

double total = onePurchase.unitPrice * onePurchase.quantity;
if (onePurchase.taxable) {
total = total * 1.05;
}

System.out.print("Total: ");
System.out.println(total);

keyboard.close();
}
}

The best way to understand the code in Listing 17-3 is to compare it, line by line, with the code in Listing 17-1. In fact, there’s a mechanical formula for turning the code in Listing 17-1 into the code in Listing 17-3. Table 17-1 describes the formula.

The two programs (in Listings 17-1 and 17-3) do essentially the same thing, but one uses primitive variables, and the other leans on the Purchase code from Listing 17-2. Both programs have runs like the one shown back in Figure 17-1.

Running code that straddles two separate files

From Eclipse’s point of view, a project that contains two Java source files is no big deal. You create two classes in the same project, and then you choose Run ⇒   Run As ⇒   Java Application. Everything works the way you expect it to work.

The only time things become tricky is when you have two main methods in the one project. This section’s example (refer to Listings 17-2 and 17-3) doesn’t suffer from that malady. But as you experiment with your code, you can easily add classes with additional main methods. You may also create a large application with several starting points.

When a project has more than one main method, Eclipse may prompt you and ask which class’s main method you want to run. But sometimes Eclipse doesn’t prompt you. Instead, Eclipse arbitrarily picks one main method and ignores all the others. This can be very confusing. You add a println call to the wrong main method, and nothing appears in the Console view. Hey, what gives?

You can fix the problem by following these steps:

1. Expand the project’s branch in the Package Explorer.
2. Expand the src folder within the project’s branch.

3. Expand the (default package) branch within the src branch.

   The (default package) branch contains .java files.

4. (In Windows) Right-click the .java file whose main method you want to run. (On a Mac) Control-click the .java file whose main method you want to run.
5. On the resulting context menu, choose Run As ⇒   Java Application.

You cannot run a project that has no main method. If you try, you get a message box like the one shown earlier, in Figure 17-2.

Why bother?

On the surface, the code in Listing 17-3 is longer, more complicated, and harder to read. But think about a big pile of laundry: It may take time to find a basket and to shovel socks into the basket, but when you have clothes in the basket, the clothes are much easier to carry. It’s the same way with the code in Listing 17-3. When you have your data in a Purchase basket, it’s much easier to do complicated things with purchases.

Understanding (or ignoring) the subtleties

Sometimes, when you refer to a particular object, you want to emphasize which class the object came from. Well, subtle differences in emphasis call for big differences in terminology. So here’s how Java programmers use the terminology:

• In Listing 17-3, the statement Purchase onePurchase = new Purchase() creates a new object.
• In Listing 17-3, the statement Purchase onePurchase = new Purchase() creates a new instance of the Purchase class.

The words object and instance are almost synonymous, but Java programmers never say “object of the Purchase class” (or if they do, they feel funny).

By the way, if you mess up this terminology and say something like “object of the Purchase class,” no one jumps down your throat. Everyone understands what you mean, and life goes on as usual. In fact, I often use a phrase like “Purchase object” to describe an instance of the Purchase class. The difference between object and instance isn’t terribly important. But it’s important to remember that the words object and instance have the same meaning. (Okay! They have nearly the same meaning.)

Making reference to an object’s parts

In the Purchase code of Listing 17-2, I declare three variables: a unitPrice variable, a quantity variable, and a taxable variable. In real-life, you might say that each purchase has three parts: the unitPrice of an item being purchased, the quantity of items purchased, and the fact that the purchase is or isn’t taxable.

When you create a Java class, each of these variables is called a field. The Purchase class has three fields — namely, the unitPrice field, the quantity field, and the taxable field.

After you’ve created an object, you use dots to refer to the object’s fields. For example, in Listing 17-3, I put a value into the onePurchase object’s unitPrice field with the following code:

onePurchase.unitPrice = keyboard.nextDouble();

Later in Listing 17-3, I get the unitPrice field’s value with the following code:

double total = onePurchase.unitPrice * onePurchase.quantity;

This dot business may look cumbersome, but it really helps programmers when they’re trying to organize the code. In Listing 17-1, each variable is a separate entity. But in Listing 17-3, each use of the word unitPrice is inextricably linked to the notion of a purchase. That’s good.

Every field is a variable, but not every variable is a field. For example, in the following code, the amount variable isn’t a field because it’s declared inside of the main method.

public static void main(String args[]) {
double amount;
amount = 5.95;
// … Etc.

One way or another, I don’t want you to get bogged down thinking about the words field and variable. A field is simply a variable that has a special role inside of a class. When I want to emphasize that special role, I use the word field. When I don’t want to emphasize that special role, I use the word variable. I may even switch back and forth between field and variable in the same sentence. Who knows? I might call something a fariable or a vield.

If you care about which word I use and when I use it, good for you. If you don’t care, don’t worry about it.

Creating several objects

After you’ve created a Purchase class, you can create as many purchase objects as you want. For example, in Listing 17-5, I create two purchase objects.

LISTING 17-5 Processing Purchases

class ProcessPurchases {

public static void main(String[] args) {
Purchase purchase1 = new Purchase();
purchase1.unitPrice = 20.00;
purchase1.quantity = 3;
purchase1.taxable = true;

Purchase purchase2 = new Purchase();
purchase2.unitPrice = 20.00;
purchase2.quantity = 3;
purchase2.taxable = false;

double purchase1Total = purchase1.unitPrice * purchase1.quantity;
if (purchase1.taxable) {
purchase1Total *= 1.05;
}

double purchase2Total = purchase2.unitPrice * purchase2.quantity;
if (purchase2.taxable) {
purchase2Total *= 1.05;
}

if (purchase1Total == purchase2Total) {
System.out.println("No difference");
} else {
System.out.println("These purchases have different totals.");
}
}
}

Figure 17-5 has a run of the code in Listing 17-5, and Figure 17-6 illustrates the concept.

To compile the code in Listing 17-5, you must have a copy of the Purchase class in the same project. (The Purchase class is in Listing 17-2.) To copy a class’s code from one project to another, see Chapter 16. (That chapter’s sidebar, “Grabbing input here and there,” describes the copy-and-paste routine.)

Listing 17-5 has two purchase objects because the code

new Purchase();

is executed two times.

Just as you can separate an int variable’s assignment from the variable’s declaration

int count;
count = 0;

you can also separate a Purchase variable’s assignment from the variable’s declaration:

Purchase purchase1;
purchase1 = new Purchase();

After you’ve created the code in Listing 17-2, the word Purchase stands for a brand-new type — a reference type. Java has eight built-in primitive types and has as many reference types as people can define during your lifetime. In Listing 17-2, I define the Purchase reference type, and you can define reference types, too.

Table 17-2 has a brief comparison of primitive types and reference types.

Classes, objects, and tables

Because classes can be mysterious, I’ll expand your understanding with another analogy. Figure 17-7 has a table of three purchases. The table’s title consists of one word (the word Purchase), and the table has three column headings: the words unitPrice, quantity, and taxable. Well, the code in Listing 17-2 has the same stuff — Purchase, unitPrice, quantity, and taxable. So in Figure 17-7, think of the top part of the table (the title and column headings) as a class. Like the code in Listing 17-2, this top part of the table tells you what it means to be a Purchase. (It means having an unitPrice value, a quantity value, and a taxable value.)

A class is like the top part of a table. And what about an object? Well, an object is like a row of a table. For example, with the code in Listing 17-5, I create two objects (two instances of the Purchase class). The first object has unitPrice value 20.00, quantity value 3, and taxable value true. In the corresponding table, the first row has these three values — 20.00, 3, and true, as shown in Figure 17-8.

Some questions and answers

Here’s the world’s briefest object-oriented programming FAQ:

• Can I have an object without having a class?

  No, you can’t. In Java, every object is an instance of a class.

• Can I have a class without having an object?

  Yes, you can. In fact, almost every program in this book creates a class without an object. Take Listing 17-5, for example. The code in Listing 17-5 defines a class named ProcessPurchases. And nowhere in Listing 17-5 (or anywhere else) do I create an instance of the ProcessPurchases class. I have a class with no objects. That’s just fine. It’s business as usual.

• After I’ve created a class and its instances, can I add more instances to the class?

  Yes, you can. In Listing 17-5, I create one instance and then another. In a for loop, I could create a dozen instances and I’d have a dozen rows in the table of Figure 17-8. With no objects, three objects, four objects, or more objects, I still have the same old Purchase class.

• Can an object come from more than one class?

  Bite your tongue! Maybe other object-oriented languages allow this nasty class cross-breeding, but in Java, it’s strictly forbidden. That’s one thing that distinguishes Java from some of the languages that preceded it: Java is cleaner, more uniform, and easier to understand.