Java Reference
In-Depth Information
Caution
If it has not already happened, then one day you may be asked to improve the performance of
a class. While it can be useful to read through the code manually, looking for known problem areas, it is
always recommended that you use a profiler—a program that will attach to your program while it is running,
and tell you where your program is spending most of its time. When you know which methods take the most
time to complete, you can look at improving their performance, rather than trying to fix random methods.
The information provided here about improving the performance of our
DvdDatabase
class is designed to
give us discussion points into several sections of the class and JDK 5. They are not necessarily the only
(or even the best) places for us to concentrate on improving our programs.
■
Reading and writing from the disk is one of the slowest operations we have to deal with.
We may also have multiple users all trying to access different records; with only one data file,
they must queue up to access the file, effectively creating a bottleneck.
When reading or writing a record, we can speed up the operation if we can go straight to
the location in the file where the record is stored. If our primary key was the record number,
we would be able to calculate the file position on the fly based on the record number multi-
plied by the size of the record. However, our application is based on using the UPC string as
the primary key, so we need a way to map UPCs to the location in the file. The only way to do
this is to read the data file at least once, storing UPCs and file locations in the map as we go.
We could create a method just to do this for us, but the interface we must implement already
has a public method that we must implement that will read the entire file and return a
List
of
the DVDs in that file, so we can piggyback that logic to populate our map.
However, there is a danger in doing this. Our constructor is relying on this method to pop-
ulate a needed field. But it is possible for the
getDVDs
method to be overridden, which would
result in our field not being populated. So we should either make this method
final
(which
will stop any other class from overriding it), or call a private method that does the same func-
tion (private methods are similar to final methods, since they cannot be overridden, because
no other class can even see them).
The
getDVDs
method is a business method. That is, we only created it because the busi-
ness requirements stated that we must—we could easily write our client application without
it. Likewise, although our implementation of it reads the entire database file from end to end,
it would be possible to implement it differently, such that it does not access the file directly
but rather calls other public methods (such as the
getDVD
method). Given this, it is possible
that somebody might later decide to override our implementation, so it would not be appro-
priate for us to make this method final.
However, the
getDVDs
method is one of the methods that we must make public according
to our provided interface.
Fortunately, we have a simple workaround for this dilemma: create a private method that
does the work, and have the
getDVDs
method call it. That way, if somebody later overrides
get-
DVDs
, our private method will still exist in the background populating our required map.
This is still not quite a perfect solution, though. In using this method to populate our
map, we will be creating the list for no purpose and discarding it immediately. Normally creat-
ing a collection and then destroying it without using it would be a bad thing, but in this case
it is more than justified. It is only the constructor that wastes this
List
, and the alternative is
to have a method that is almost identical but exists only to populate our map. Here is our
