Java Reference
In-Depth Information
Listing 8-10.
The DVDTableModel's Internal Members That Hold the Table Rows
private String [] headerNames = {"UPC", "Movie Title", "Director",
"Lead Actor", "Supporting Actor", "Composer",
"Copies in Stock"};
private List<String[]> dvdRecords = new ArrayList<String[]>(5);
Remember that Model objects act as data containers. The View object that transforms a
Model into a display format does not require knowledge of how they internally represent data.
On a very abstract level, tables encapsulate two things:
•
The names of the columns
•
The data contained in each row
These two items require a
TableModel
to internally represent two types of collections: one
that contains a list of header names and one that contains a list of row values. The only deci-
sion that remains is what type of collection is appropriate to represent these two types of data.
In the case of the
JTable
contained in our client application, the header names will
remain the same throughout the life of the application. Therefore, an array of
String
objects
will be the perfect data structure to hold the column names. Next, the row column values for
each row are immutable in the sense that once a row is created, the number of values in a row
does not need to change. Thus, an array of
String
values can also represent a row of
DVD
data.
The actual collection that holds the rows is entirely different from the table headers and
column data in that the number of rows changes—and changes quite often. If a user searches
for a list of
DVD
records, there is no way to ensure how many rows will result, and therefore it
will be impossible to anticipate the size of the data structure required to hold the values. The
best option to hold rows of data is a dynamic collection that can have values easily appended,
removed, and iterated through. The order of the results also matters, so a set collection is
obviously a poor choice. The best choice is some type of dynamic list. The list can now be
narrowed to a
Vector
, a
LinkedList
, or an
ArrayList
. As mentioned in the “Internally Synchro-
nized Classes” section of Chapter 4,
Vector
s provide little benefit in most cases, but can provide
a false sense of thread safety—we therefore generally recommend against their use. In this par-
ticular case, the values in our
TableModel
do not have to be thread-safe because only one thread
is manipulating their values in a single instance. Thus, a
Vector
provides unneeded overhead in
this application without providing any benefits. A
LinkedList
provides us with some additional
methods over an
ArrayList
—specifically the ability to add and remove the first and last objects
in the collection; however, we do not need this additional functionality. The best choice for the
representation of
DVD
data rows in our
TableModel
is clearly an
ArrayList
.
Next, our
TableModel
must implement some of the required methods that the
JTable
uses to render the Model into a View. For instance, the
TableModel
must have a way to inform
the
JTable
of how many columns it encapsulates. The method
getColumnCount
shown in
Listing 8-11 provides this functionality.
Listing 8-11.
Our TableModel's getColumnCount Method
public int getColumnCount() {
return this.headerNames.length;
}
