- CourseSession
- Enrolling Students
- int
- Initialization
- Default Constructors
- Suites
- The SDK and java.util.ArrayList
- Adding Objects
- Incremental Refactoring
- Objects in Memory
- Packages and the import Statement
- The java.lang Package
- The Default Package and the package Statement
- The setUp Method
- More Refactoring
- Class Constants
- Dates
- Overloaded Constructors
- Deprecation Warnings
- Refactoring
- Creating Dates with Calendar
- Comments
- Javadoc Comments
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
Class Constants
It is never a good idea to embed literals directly in code, as mentioned earlier. Declaring a local variable as final, which prevents other code from reassigning its value, is a good idea. The final keyword tells other developers that "I don't intend for you to be able to change the value of this variable."
Frequently you will need more than one class to use the same literal. In fact, if you are doing test-driven development properly, any time you create a literal in code, it is there by virtue of some assertion in a test method against that same literal. A test might say, "assert that these conditions produce an error and that the error message is such-and-such a message." Once this test is written, you then write the production code that produces such-and-such an error message under the right conditions. Now you have code duplication—"such-and-such an error message" appears in both the test and the production code.
While a few duplicated strings here and there may seem innocuous, overlooking the need to refactor out this duplication may prove costly in the future. One possibility is related to the growth of your software. Initially you may only deploy your system to local customers. Later, as your software achieves more success, the business may decide that it needs to deploy the software in another country. You will then need to internationalize your software, by deploying it with support for other languages and with consideration for other cultures.
Many software developers have encountered this problem. The software they worked on for months or years has hundreds or thousands of literal Strings strewn throughout the code. It is a major effort to retrofit internationalization support into this software.
As a craftsman of Java code, it is your job to stay vigilant and ensure that duplication is eliminated as soon as you recognize it. [5]
 |
Replace common literals with class constants. |
A class constant is a field that is declared with the static and final keywords. As a reminder, the final keyword indicates that the field reference cannot be changed to point to a different value. The static keyword means that the field is available for use without having to first construct an instance of the class in which it is declared. It also means that there is one and only one field in memory instead of one field for each object created. The following example declares a class constant:
class ChessBoard {
static final int SQUARES_PER_SIDE = 8;
}
By convention, class constants appear in uppercase letters. When all letters are uppercase, camel notation is not possible, so the standard is to use underscores to separate words.
You can refer to the class constant by first specifying the class name, followed by the dot (.)operator, followed by the name of the constant.
int numberOfSquares = ChessBoard.SQUARES_PER_SIDE * ChessBoard.SQUARES_PER_SIDE;
You will use class constants already defined in the Java class library in the next section on Dates. Shortly thereafter you will define your own class constant in the CourseSession code.