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