The DvdDatabase Class - SCJD Exam with J2SE 5 - page 123

It might also be noted that there are no calls to the logger in the second instantiator. Since
this instantiator immediately calls the third instantiator, we are relying on the logging avail-
able there.
For each variable listed in lines 89-129, we have a getter and a setter. For example, the
composer variable specified in line 100 has a getComposer getter and a setComposer setter as
follows:

199 public String getComposer() {
200 log.entering("DVD", "getComposer");
201 log.exiting("DVD", "getComposer", this.composer);
202 return this.composer;
203 }
...
211 public void setComposer(String composer) {
212 log.entering("DVD", "setComposer", composer);
213 this.composer = composer;
214 log.exiting("DVD", "setComposer", this.composer);
215 }

Using getters and setters (so named because the first verb of the method is either get or
set) enables us to expose only the sections of the method we want to expose, and allow only
certain operations on them. For example, we might decide that the number of copies of a DVD
can never go below zero; if we allow clients to directly modify the field, then they can set it to
any number they like, including negative numbers. But by having a setter for numbers of DVDs,
we can include our business logic to ensure that the client cannot set a negative number.

Note In line 200 we call log.entering and then call log.exiting immediately afterwards in line 201.
As always, there was a design decision to be made here: Do we create our own log message (probably call-
ing log.finer ), or do we use the two calls that really don't provide much useful information? Once again,
there is no one “right” way to handle this. The disadvantage of our chosen method is that we are providing
unnecessary logging, which does not produce much useful information. However, on the positive side we are
still using the same standard logging format for all “entering” and “exiting” log messages—contrast this
with the probability that if we were to write our own specialized log method for these getters and setters, it
is likely that the log messages would vary from method to method. In addition, if we ever needed to do more
work in this method, the work can be put directly between the two log messages; if we had created our own
specialized log message, we would probably have to remove it and replace it with the standard log messages.

■

The logging provided for the getters and setters is possibly overkill; however, it does high-
light one valuable debugging tool: It can be very useful to see what parameters are passed into
a method, and what the end result of executing the method is. By logging the composer method
parameter at line 212, we will have a record of what was passed into the method, and by log-
ging the this.composer instance variable at line 214, we will have a record of what the end
result of executing the setComposer method was. If at a later date this method is updated (for
example, adding code to ensure the first letter of each part of the composer's name is capital-
ized), we will still get logging showing what the input and results are.