Java Reference
In-Depth Information
MailItem
. Then there was a call to the
print
method of the mail item. Using abstraction,
we can view the
print
method as a single command. Or, if we are interested in more detail,
we can go to a lower level of abstraction and look inside the
print
method.
In a similar style, we can use the debugger to observe one object creating another. The
send-
Message
method in the
MailClient
class shows a good example. In this method, a
MailItem
object is created in the first line of code:
MailItem item = new MailItem(user, to, message);
The idea here is that the mail item is used to encapsulate a mail message. The mail item con-
tains information about the sender, the recipient, and the message itself. When sending a mes-
sage, a mail client creates a mail item with all this information and then stores the mail item on
the mail server. There it can later be picked up by the mail client of the recipient.
In the line of code above, we see the
new
keyword being used to create the new object, and we
see the parameters being passed to the constructor. (Remember: Constructing an object does
two things—the object is being created and the constructor is executed.) Calling the constructor
works in a very similar fashion to calling methods. This can be observed by using the
Step Into
command at the line where the object is being constructed.
Exercise 3.41
Set a breakpoint in the first line of the
sendMailItem
method in the
MailClient
class. Then invoke this method. Use the
Step Into
function to step into the
constructor of the mail item. In the debugger display for the
MailItem
object, you can see
the instance variables and local variables that have the same names, as discussed in Section
3.12.2. Step further to see the instance variables get initialized.
Exercise 3.42
Use a combination of code reading, execution of methods, breakpoints,
and single stepping to familiarize yourself with the
MailItem
and
MailClient
classes.
Note that we have not yet discussed enough for you to understand the implementation of
the
MailServer
class, so you can ignore this for now. (You can, of course, look at it if you
feel adventurous, but don't be surprised if you find it slightly baffling…) Explain in writing how
the
MailClient
and
MailItem
classes interact. Draw object diagrams as part of your
explanations.
3.15
Summary
In this chapter, we have discussed how a problem can be divided into sub-problems. We can
try to identify subcomponents in those objects that we want to model, and we can imple-
ment subcomponents as independent classes. Doing so helps in reducing the complexity
of implementing larger applications, because it enables us to implement, test, and maintain
individual classes separately.
We have seen how this results in structures of objects working together to solve a common task.
Objects can create other objects, and they can invoke each other's methods. Understanding
these object interactions is essential in planning, implementing, and debugging applications.
We can use pen-and-paper diagrams, code reading, and debuggers to investigate how an appli-
cation executes or to track down bugs.
Search WWH ::
Custom Search