In the courses that you take with me I define a bean as a class used to aggregate or collect both primitive data types and other classes for modelling data in a program. Most programs require the definition of multiple elements or values to describe the data that they interact with. Rather than list each element individually, these elements are grouped together into a single class.
The original concept of a bean called a JavaBean dates to 1996. It was intended to be a component model for visual elements of a program. These components could then be easily manipulated by a visual modelling tool. You can read the current specification at http://tinyurl.com/ybzwmldq that was last updated in 1997.
I require you to use a subset of this original concept that I refer to as a bean class in the programs that you write for the courses you are taking with me. Here is the rundown of the rules for a bean in my courses:
- All fields, also called instance variables or properties, can only be private.
- There must be a default constructor.
- Methods to read or write the instance variable must begin with the prefixes set or get.
- The bean class should implement the serializable interface
- The bean class should have a toString method.
- The bean class should have a hashCode and an equals method
- The bean class should implement the Comparable interface and have a compareTo method.
- The companion Comparable object for when you need to have more than one possible comparison
- The Java 8 lambda implementation of of a Comparator
- The Java 8 functional implementation of a Comparator
For example, consider a problem where it is necessary to model a book. Here is the basic bean.
The methods for reading and writing must adhere to the naming convention. They must begin with set, get or is all in lower case. The is prefix is an alternative to get when the type of value returned is a boolean. They must be followed by a capital letter. They usually correspond to the private fields in the class. You may also add any additional methods that your logic may require.
You now have a class that models a book. Any part of your code now requires only a single reference to an object of type Book to represent all the data points or fields for a book. Reading or writing to any field must now go through a method. The serializable interface allows the state of the object to be preserved by writing it to disk. For distributed applications, such as web services, this allows the object to be transmitted over the internet. Review the documentation on serialization as not every class type can be serialized without additional code. Primitives and Strings can be serialized without additional code.
Special Note 1:
I had a paragraph here that incorrectly stated that a serializable object required a default constructor and set methods but it was pointed out by Michael Simons @rotnroll666 that this is incorrect. I should have reviewed the documentation that I recommended that you review. Serialization does not require a default constructor or set methods.
Notice that all the parameters in the methods are final. A final variable cannot have its value changed. If you pass a reference as an argument to any method that does not declare its parameter as final you can change the address that the argument points to and this can result in an unintended side effect. Bean classes must never change an argument.
An argument is a value or reference passed to a method. A parameter is the place holder in the method signature that will represent the argument’s value in the method.
Primitive argument types such as int or double have no connection to the original value from the caller so final is not required. However, it is a best practice to declare it final as you should not be changing it.
We now have a proper bean class. There are four additional methods that can be added that will make the bean more useful in certain circumstances. The first of these circumstances is when you need to represent the bean as a string. The most common reason is to support debugging by allowing you to examine the value of each field in the bean in a log statement. This is the job of the toString method.
The toString method is inherited from the superclass Object that every class in Java extends. The annotation @Override, while optional, makes it clear that you are overriding a superclass method. What you put into the string is up to you. For example, when placing an object into GUI tree, the toString method is the default for what should appear on screen in the tree and so may return the value of a single field.
hashCode and equals
The next two methods are hashCode and equals. These should always go together whenever your code must test if two objects have identical values in their fields. It may appear that equals is all you need but there is a performance issue here. Our Book class has 4 String fields. When comparing two Book objects it will be necessary to compare every character in every string to determine if they are equal. The hashCode method creates an integer value called a hash code that represents all the values in the object. This value can be compared to the corresponding value in the object we are comparing to. If the value of the hash code is not the same then we know with certainty that they do not possess the same values.
Hash codes are not unique. It is possible that two objects with different values may return the same hash code. Therefore, if hash codes are equal we must call upon the equals method to be certain they are the same. Hash codes are used in Java collections data structures. If you intend to use such a structure, such as a HashMap or a HashSet then you must have hashCode and equals in the bean.
These two methods were generated by the IDE that I use, NetBeans. Most IDEs such as Eclipse and IntelliJ will generate these methods. You may choose to exclude certain fields from these methods but the fields you are using must be the same in hashCode and equals.
Special Note 2:
It has been mentioned in the comments that as presented this hashCode method is problematic when used in a Hash data structure. The fields in the class are mutable/changeable and this could result in an object placed in the hash structure that can never be found if a field is changed. This is a type of memory leak. The solution is to make all fields used to construct the hash code final/immutable.
Special Note 3:
This next section has been rewritten from the first version of this article based on comments from Michael Simons @rotnroll666, Originally I proposed multiple Comparable interfaces and multiple compareTo methods in the bean. Michael pointed out that this will result in code bloat as the bean will keep getting longer with each additional compareTo method. He recommended Comparable objects that exist outside the bean.
Comparable Interface and compareTo
You have two choices for how you can order objects when using sort methods or self sorting collections such as a Map. The first choice is to implement a compareTo method in the bean. This method is required when you implement the Comparable interface. This sorted order that results is called the natural ordering and the compareTo method is referred to as the natural ordering method. You must decide which fields will contribute to the sort order criteria. I wish to be able to sort the books by their title.
I am taking advantage of the fact that String objects implement the Comparable interface. If my title, this.title, comes before the title in the Book parameter then the difference in the ASCII codes for the first differing characters is returned as a negative value. If the strings are identical then 0 is returned. If my title comes after the title in the Book parameter then the difference in the ASCII code for the first differing characters is returned as a positive value
You can have only one compareTo method that overrides the Comparable interface requirement. This leads to the second approach to comparisons. If you need multiple comparisons each with different fields as the criteria then your best solution is to create Comparable objects. This way you can compare any parts of the objects. You just need a Comparable object for each comparison and the original bean does not change.
The Comparable interface lends itself to the use of lambda expressions that is demonstrated in the test code. This eliminates the need for a Comparable object. However, if the logic to determine the sorting order is more than three lines long you might be better off with a Comparator object instead. Here is what the the two comparison approaches look like when used to sort an array.
Java 8 Functional Comparator
Java 8 introduced new methods in the Comparator interface that simplifies comparisons with objects. I wish to sort my books based on the ISBN number. As an integer has a natural order, I can inform the sorting method what Comparator to use by the following.
See the test program just below to see how Comparable and Comparator work.
The Complete Bean
Here is the final version of the Book bean.
The Bean Tester
Here is a test program that demonstrates the two ways that comparisons can be made, The comments describe which approach is used.
The output of this program will be:
Bean classes are required when using several libraries in Java such as Context Dependency Injection (CDI) and Bean Validation. You will also use bean classes to represent data from a database when using Java Database Connectivity (JDBC). Beans that back JavaFX controls are coded differently but are 100% backward compatible with simple bean classes. See my next article on JavaFX beans.