Information Technology Reference
In-Depth Information
the reusability of components, assuming that the component in question is generic
enough to both be used in different contexts and to capture the common features of
those contexts (D'Sourza and Wills
1999
). For this reason, software engineers
often look to enhance the generic quality of components. This can be performed in
several ways, and may result in the modification of a class created for some
specific purpose and circumstance, into a more general class which can then be
implemented in various other contexts. The use of various forms of inheritance
through the creation of templates and abstract classes work toward this end.
2.5.4 Interfaces
We have described the concept behind interfaces at various points throughout this
chapter. Simply put, an interface is a system that allows two separate entities to
interact with each other. It does this by closing off an object's outward appearance
from its inner workings and by providing a set of methods for interaction. As we
have said, the interface is not unique to software engineering, but is a common
feature that can be found in countless forms: spoken language acts as an interface
between people, a keyboard is an interface into a computer, a faucet handle is an
interface for controlling water in a sink, and a mouth is an interface between an
animal and the food that it consumes.
In software engineering, the use of an interface defines a manner for interacting
with a class or an object. In some programming languages an interface is itself a
data type, just like any other class. Like a class, an interface defines a set of
methods, however, unlike a class the interface never implements those methods.
Instead, an interface is used by a class, which implements those methods for its
own use. A class can even make use of multiple interfaces to allow for different
manners of interaction.
In the example that we have used throughout this chapter, the
monster_truck
class and its class hierarchy define what a
monster_truck
is; what it can and
cannot do. A monster truck, however, can be used in other ways. For instance, a
monster truck sitting at a car lot must be inventoried, inspected and categorized
according to various characteristics, including price. The system responsible for
managing the lot's inventory does not care one bit about interacting with a monster
truck in the way that a driver would, nor does it care whether or not it is managing a
monster truck at all. So, instead of accessing our
monster_truck
class as defined
by its normal implementation, the inventory system might set up some other sort of
communication protocol to communicate information such as price and model
number. The system that it creates, of course, is just another interface through which
we are now able to interact with the
monster_truck
class. For this system to
work, both the
monster_truck
class and the inventory system must agree to this
protocol by implementing their own forms of the interface, and thus all of the
methods defined in that interface.
