Classes and Objects: A Deeper Look - Java: How to Program Early Objects - page 344

Software Engineering Observation 8.11
Declaring an instance variable as final helps enforce the principle of least privilege. If an
instance variable should not be modified, declare it to be final to prevent modification.
For example, in Fig. 8.8, the instance variables firstName , lastName , birthDate and
hireDate are never modified after they're initialized, so they should be declared final .
We'll enforce this practice in all programs going forward. You'll see additional benefits of
final in Chapter 23, Concurrency.
Common Programming Error 8.8
Attempting to modify a final instance variable after it's initialized is a compilation error.
Error-Prevention Tip 8.5
Attempts to modify a final instance variable are caught at compilation time rather than
causing execution-time errors. It's always preferable to get bugs out at compilation time,
if possible, rather than allow them to slip through to execution time (where experience has
found that repair is often many times more expensive).
Software Engineering Observation 8.12
A final field should also be declared static if it's initialized in its declaration to a value
that's the same for all objects of the class. After this initialization, its value can never
change. Therefore, we don't need a separate copy of the field for every object of the class.
Making the field static enables all objects of the class to share the final field.
8.14 Package Access
If no access modifier ( public , protected or private —we discuss protected in
Chapter 9) is specified for a method or variable when it's declared in a class, the method
or variable is considered to have package access . In a program that consists of one class
declaration, this has no specific effect. However, if a program uses multiple classes from the
same package (i.e., a group of related classes), these classes can access each other's package-
access members directly through references to objects of the appropriate classes, or in the
case of static members through the class name. Package access is rarely used.
Figure 8.15 demonstrates package access. The app contains two classes in one source-
code file—the PackageDataTest class containing main (lines 5-21) and the PackageData
class (lines 24-41). Classes in the same source file are part of the same package. Conse-
quently, class PackageDataTest is allowed to modify the package-access data of Package-
Data objects. When you compile this program, the compiler produces two separate .class
files— PackageDataTest.class and PackageData.class . The compiler places the two
.class files in the same directory. You can also place class PackageData (lines 24-41) in
a separate source-code file.
In the PackageData class declaration, lines 26-27 declare the instance variables
number and string with no access modifiers—therefore, these are package-access instance
variables. Class PackageDataTest 's main method creates an instance of the PackageData
class (line 9) to demonstrate the ability to modify the PackageData instance variables
directly (as shown in lines 15-16). The results of the modification can be seen in the
output window.