- Packages
- Documentation with JavaDoc
- Field Defaults and Field Initializers
- Polymorphism
- Constructors
- static Methods
- The this Reference
- Stack and Heap Memory
- Putting Things Together
- What's Next
This chapter is from the book
This chapter is from the book
This chapter is from the book
7.3 Field Defaults and Field Initializers
Local variables do not have a default value. They cannot be used until they are initialized. By contrast, class fields are automatically initialized to the default values for their types. As you may recall from Chapter 3, fields are set to 0 or null or false by default, depending on their type. It is a good idea, however, to set your instance fields to something you can use and not just leave them with their defaults.
As you might imagine, initializing a class field value looks like this:
public int i = 3; public static boolean b = true;
The syntax here is useful if you want to have all of a class's constructors set your instance field to the same value. You can initialize objects through initialization expressions for fields and in constructor code. Classes have class initialization methods that are like constructors. The difference is that constructors allow you to define the body of those methods, and class initialization methods don't.
The way to initialize class fields is with something called a static initializer. A static initializer is the keyword static followed by code in curly braces.
You declare a class field much as you would declare a local variable. The chief difference is that field declarations do not belong to any method. For that reason, they cannot be executed like statements. The main thing to remember about class fields is that they are associated with the class itself, not with an object, so they must be initialized before a constructor is called.
7.3.1 final Instance Fields
An instance field can be defined as final. If you want to do this, you must initialize the instance field when you construct the object (see "Constructors" below). That makes sure it has a value, and the value cannot be modified again in the lifetime of the object.
Instance fields are declared final using the final keyword:
class MyClass {
private final int ID;
}
In general, it is a good idea to mark as final whatever you can. If you think you'll never need a mutator method for the field, then the field is probably a good candidate to be final. However, be careful that the value really will never need to change. While "name" seems like a reasonable choice for final, there are numerous reasons for a name to change: people get married, have their names legally changed, get divorced, decide to start using their middle initial, and so on.
7.3.2 System.out.println()
Here is an example to illustrate the usage of class fields. Because we have used it so frequently, it is important to understand what is happening when you use System.out.println() to print something out to the command line. What exactly is going on? Now that you know more about classes and methods, it may be apparent: In the java.lang package is a class called System, which cannot be instantiated. It has three class fields: err (the standard error output stream), in (the standard input stream), and out (the standard output stream). These refer to PrintStream objects. A PrintStream object is defined in the java.io (input/output) package. The PrintStream object takes a method called println().
7.3.3 Signatures and Headers
Methods are a key aspect of Java programming. They look similar to the ColdFusion functions we're used to, and in some cases they act similarly. There are even certain Java methods that are just about the same as ColdFusion functions, such as #abs(a)# and java.lang.abs(int a). However, because Java is object oriented, defining methods can be a far more complex task than writing ColdFusion UDFs. We have been working with Java methods throughout the book, and in different sections in this chapter we will look at the aspects of Java methods that distinguish them as an object-oriented language.
The signature of a method is composed of its name along with its parameter list. The header of a signature is composed of the signature, any modifiers (such as public or static), and the list of exceptions thrown. The HTML Java API documentation consists of such headers.
We need to have signatures in Java, and not in ColdFusion, because Java is object oriented and ColdFusion isn't. Signatures help us keep things straight, which can be difficult given polymorphism—the subject of the next few sections.