Java Reference
In-Depth Information
provide any parameters at all, and assume that the data file is in the current working directory.
However, we also know that this class will be used in a server environment, and in such cases,
it is common for the data file to reside in a different directory (and sometimes a different hard
drive) than the application. In this case, we would need to be able to specify the directory
where the data file can be found.
The first constructor is just a special case of the second constructor, and as such we might
be tempted to leave it out. We should make a decision on whether it will be used often. If so,
adding the constructor will make our users happy. If not, we can leave the constructor out,
thereby simplifying our code, and in the rare cases where a user wants to use a database in the
current working directory they can call the constructor that takes a directory as a parameter
with the current working directory (
System.getProperties("user.dir")
) as the parameter.
We have decided to leave both constructors in the class, primarily to demonstrate the
technique of having one constructor call the other constructor. This is a very common way of
handling overloaded methods and constructors, as it ensures that the same business logic is
executed no matter which version gets called.
Our constructors are going to open the data file, which means we could get a
FileNotFoundException
if the file is not in the specified directory, and we could get an
IOException
if there is a problem with opening the data file (for example, if we don't have
adequate permissions). We're faced with the decision of handling them within our construc-
tor, or passing them back to the calling class.
Another way of thinking about this issue is, what can we realistically do if we get either of
those exceptions? About the only thing we can do within our
DvdDatabase
class is try the oper-
ation again, but if the file does not exist when we first look for it, is it likely to be there the
second time we look for it? We cannot simply log these exceptions and ignore them; then the
user will think that the
DvdDatabase
class was instantiated correctly and is ready for use when
it isn't. So we have chosen to pass these exceptions back to the class that is constructing the
DvdDatabase
.
■
Tip
To keep this project simple, we have elected to rethrow the
FileNotFoundException
and
IOException
, but in doing this we have implicitly declared that we are dealing with a file-based data store.
A future enhancement might be to convert this backing store to a SQL database, in which case these excep-
tions would no longer apply. A better solution might be to create our own
DatabaseFailureException
, and
wrap
FileNotFoundException
and
IOException
in it where necessary. This way, if we later change to a
SQL database, we could similarly wrap the SQL exceptions within the same
DatabaseFailureException
,
and the client code should still continue to work. Doing this is left as an exercise for the reader.
For each method in our
DBClient
interface, we create a method that calls the appropriate
method in our worker classes:
