Java Reference
In-Depth Information
You, as the user of a vending machine, are like the client of the ADT bag that you saw earlier
in this chapter. The observations that we just made about the user of a vending machine are similar
to the following observations about a bag's client:
The client can perform only the operations specific to the ADT bag. These operations often
are declared within a Java interface.
●
The client must adhere to the specifications of the operations that the ADT bag provides.
That is, the programmer of the client must understand how to use these operations.
●
The client cannot access the data within the bag without using an ADT operation. The princi-
ple of encapsulation hides the data representation within the ADT.
●
The client can use the bag, even though the programmer does not know how the data is stored.
●
If someone changed the implementation of the bag's operations, the client could still use the
bag in the same way, as long as the interface did not change.
●
1.20
In the examples of the previous section, each bag is an instance of a class that implements the ADT
bag. That is, each bag is an object whose behaviors are the operations of the ADT bag. You can
think of each such object as being like the vending machine we just described. Each object encap-
sulates the bag's data and operations, just as the vending machine encapsulates its product (soda
cans) and delivery system.
Some ADT operations have inputs analogous to the coins you insert into a vending machine.
Some ADT operations have outputs analogous to the change, soda cans, messages, and warning
lights that a vending machine provides.
Now imagine that you are the designer of the front, or interface, of the vending machine. What
can the machine do, and what should a person do to use the machine? Will it help you or hinder you
to think about how the soda cans will be stored and transported within the machine? We maintain
that you should ignore these aspects and focus solely on how someone will use the machine—that
is, you focus on designing the interface. Ignoring extraneous details makes your task easier and
increases the quality of your design.
Recall that abstraction as a design principle asks you to focus on
what
instead of
how
. When
you design an ADT, and ultimately a class, you use data abstraction to focus on what you want to
do with or to the data, without worrying about how you will accomplish these tasks. We practiced
data abstraction at the beginning of this chapter when we designed the ADT bag. As we chose the
methods that a bag would have, we did not consider how we would represent the bag. Instead, we
focused on what each method should do.
Ultimately, we wrote a Java interface that specified the methods in detail. We were then able to
write a client that used the bag, again without knowledge of its implementation. If someone wrote
the implementation for us, our program would presumably run correctly. If someone else gave us a
better implementation, we could use it without changing our already-written client. This feature of
the client is a major advantage of abstraction.
As we mentioned at the end of Appendix B, the Java Class Library is a collection of classes and inter-
faces that Java programmers use as a matter of course. From time to time, we will present members of
the Java Class Library that are like or relevant to our current discussion. The
Java Collections
Framework
is a subset of this library that provides us with a uniform way of representing and work-
ing with collections. Many of the classes and interfaces in the Java Class Library that we will note are
a part of this framework, although we usually will not point out this fact.
