Page 291
by Jonathan Gennick
PL/SQL does objects! One of the exciting new features of the Oracle8
database is support for object-oriented programming. With Oracle8 and PL/SQL
release 3.0, it is now possible to define object classes, instantiate objects, and save
those objects in the database. The benefits to you are increased opportunities
for abstraction and for writing reusable code. If you have Oracle8 available to
you, read through this chapter carefully and take the time to fully understand
how Oracle's new object-oriented features work, and how you can take advantage
of them. If you don't yet have access to Oracle8, you will not be able to do
any of the examples or exercises in this chapter. In that case, you might want to
skim through it lightly now, in order to become familiar with the new
features, and then revisit it later when you do have Oracle8 available.
Page 292
Let's begin by reviewing the basics of object-oriented programming (OOP). There is really no magic to object-oriented programming. It's simply a different way of organizing code and data within your programs, one that you can take advantage of in order to model your code to more closely match the real world. There are three pillars of good object-oriented design:
Each of these is described in more detail in the following sections, using as examples some real-world objects that you interact with every day.
NEW TERM
The term encapsulation refers to the fact that each object "takes care of itself." A
well-designed object has a clear and well-defined interface that is used to manipulate
the object. All the program code necessary to perform any function on the object is
contained within the object definition itself. Thus an object is completely self-contained and can
be "dropped in" anywhere you need it.
A classic, and often used, real-world example of objects is audio/video components. Say you are setting up a home theater. You drive down to the nearest appliance superstore and pick out whatever objects interest you, say a big-screen TV, an FM tuner, an amplifier, and some speakers. All these components have well-defined interfaces, and each contains whatever internal electronics and software are necessary to make them work. The FM tuner will tune in radio stations regardless of whether or not you plug it into the amplifier. The TV does not need any circuitry that might be present in the speakers. After integrating all these components, you might decide that you also want a subwoofer. Adding one is simple. You don't have to rebuild your stereo system. You just run back to the store, buy the desired component, come home, and plug it in.
It all sounds like nirvana, but there are some gotchas. In real life, interfaces are not always compatible and sometimes components have overlapping functionality. That amplifier, for example, might also have a built-in tuner, and how often have you had to buy an adapter to mate two incompatible connectors? Often it's easier to work with components that have all been built by the same manufacturer and that have been designed to work together. The same is true of object-oriented programming.
Page 293
NEW TERM
Inheritance refers to the fact that as programmers design new objects, they often
build on objects that have been created previously. In other words, programmers can
create new objects that inherit the functionality of previously created objects. Sometimes when
you do this, you might choose to modify the inherited functionality, and almost certainly you
will want to add new functionality. The telephone is a good example of this. Originally it was
a very simple device. You picked up the phone, listened for a dial tone, and dialed a
number using a rotary dial. When pushbutton phones came out, the original functionality
was inherited, except for the dialing interface, which was replaced by buttons. Cordless
phones inherited this functionality, added a radio to the implementation, and added an on/off
switch to the handset interface so that the handset did not need to be returned to the cradle after
each call.
One big advantage of inheritance in the programming world, which is not present in the physical world, is that you can change the definition of a software object and the change will propagate through all objects of that type, all objects inherited from those objects, and so forth. Think of changing the definition of a telephone to include pushbutton dialing and have all rotary phones in the world suddenly transform themselves. Of course that can't be done, but the software equivalent of it can be.
NEW TERM
Polymorphism enables different objects to have methods of the same name
that accomplish similar tasks, but in different ways. Think back to your home
entertainment system for a moment. Each of the components has an on button. The TV also has
a remote with an on button. Each of these buttons can invoke different processes inside
each piece of equipment. The remote, for example, has to send an infrared beam of light to
the TV set when the on button is pushed. In spite of the fact that each on button invokes
a different sequence of events, each button is still labeled "on." It would be quite
inconvenient if this were not the case. Consistent naming frees your mind from having to
remember specifically for each device how to turn it on. You quickly become conditioned to
pushing the on button, or flipping a switch to on, no matter what device you are using. It
becomes second nature.
Polymorphism enables your software objects to use method names that are consistent with the function being performed even though the way in which that function is implemented can differ from object to object.
NEW TERM
The term class refers to the definition for an object. Like a blueprint for a house,
it tells you everything you need to build an object, and it tells you what that object
will look like when it is built. An employee class, for example, might be created to contain
all attributes of an employee. Examples of employee attributes would be pay rate, name,
address, and so on.