chap11.htm

Since the field of object oriented programming is probably new to you, you will find that there is a

<P><B>THE LINKED LIST IMPLEMENTATION</B>

<P>Example program ------> <B><A HREF="ELEMLIST.CPP">ELEMLIST.CPP</A></B>

<P>The file named ELEMLIST.CPP is the implementation for the linked list
classes and should be self explanatory if you understand how a singly linked
list operates. All new elements are added to the end of the current list.
This was done to keep it simple but an alphabetic sorting mechanism could
be added to sort the employees by name if desired. This will be used to
store a list of employees as described earlier in this chapter. You will
notice that if memory cannot be allocated, the program simply exits. This
is not acceptable for a production program that must be competitive in
the marketplace. Error recovery is a major topic and one you will need
to study someday.

<P>The method to display the list simply traverses the list and calls the
method named <B>display()</B> in line 30 once for each element of the list.

<P>It is important for you to take notice that in this entire class, there
is no mention made of the existence of the three derived classes which
we desribed earlier in this chapter, only the base class named <B>person
</B>is mentioned. The linked list therefore has no hint that the three
subclasses even exist, but in spite of that, we will see this class send
messages to the three subclasses as they are passed through this logic.
That is exactly what dynamic binding is, and we will have a little more
to say about it after we examine the calling program.

<P><B>USING THE LINKED LIST</B>

<P>Example program ------> <B><A HREF="EMPLOYE2.CPP">EMPLOYE2.CPP</A></B>

<P>At this time you should examine the example program named EMPLOYE2.CPP
for our best example of dynamic binding in this tutorial, yet the program
is kept very simple.

<P>This program is very similar to the example program named EMPLOYEE.CPP
with a few changes to better illustrate dynamic binding. In line 7 we define
an object of the class <B>employee_list</B> to begin our linked list. This
is the only copy of the list we will need for this program. For each of
the elements, we allocate the data, fill it, and send it to the linked
list to be added to the list where we allocate another linked list element
to point to the new data, and add it to the list. The code is very similar
to the last program down through line 40.

<P>In line 43 we send a message to the <B>display_list() </B>method which
outputs the entire list of personnel. You will notice that the linked list
class defined in the files named ELEMLIST.H and ELEMLIST.CPP are never
informed in any way that the subclasses even exist but they dutifully pass
the pointers to these subclasses to the correct methods and the program
runs as expected.

<P><B>WHAT GOOD IS ALL OF THIS?</B>

<P>Now that we have the program completely debugged and working, suppose
that we wished to add another class to the program. For example, suppose
we wished to add a class named <B>consultant </B>because we wished to include
some consultants in our business.

<P>We would have to write the class of course and the methods within the
classes, but the linked list doesn't need to know that the new class is
added, so it doesn't require any changes in order to update the program
to handle <B>consultant </B>class objects. In this particular case, the
linked list is very small and easy to understand, but suppose the code
was very long and complex as with a large database. It would be very difficult
to update every reference to the subclasses and add another subclass to
every list where they were referred to, and this operation would be very
error prone. In the present example program, the linked list would not
even have to be recompiled in order to add the new functionality.

<P>It should be clear to you that it would be possible to actually define
new types, dynamically allocate them, and begin using them even while the
program was executing if we properly partitioned the code into executable
units operating in parallel. This would not be easy, but it could be done
for a large database that was tracking the inventory for a large retail
store, or even for an airlines reservation system. You probably have little
difficulty understanding the use of dynamically allocated memory for data,
but dynamically allocating classes or types is new and difficult to grasp,
but the possibility is there with dynamic binding.

<P>If you were very alert, you noticed that we have no provision to deallocate
either the elements of the list or the list itself. To add it, we would
need to add a method to the <B>employee_list</B> class, possibly named
<B>delete_person()</B>, and add a destructor to the <B>employee_data </B>class
.

<P><B>AN APPLICATION FRAMEWORK</B>

<P>Example program ------> <B><A HREF="APPFRAM1.CPP">APPFRAM1.CPP</A></B>

<P>The example program named APPFRAM1.CPP illustrates the method used to
write an application framework. If you do much serious programming, you
will encounter one because they provide so many benefits for the MS Windows
programmer. There are application frameworks available for other operating
systems too, so most programmers should be familiar with them.

<P>The class named <B>CForm</B> is the base class for our trivial but important
example, and it consists of four methods but no data members. The diligent
student will note that the method named <B>display_form</B> calls the other
three members to actually do the work of displaying our little form on
the monitor. There is nothing magic about this program except that it is
the framework for a very interesting concept used by all of the application
frameworks currently available. Note that three of the methods are declared
as virtual in lines 9 through 11.

<P>The interesting part occurs when we inherit the class into our new class
named <B>CMyForm</B> in line 27 and write new methods for two of the base
class methods. We have inherited as much functionality from the base class
as we liked, and written new methods for those that didn't serve our purpose
as originally written. When we finally execute an object of the new class
in line 42 of the main program, we do indeed use part of the base class,
and override those parts that we explicitly wrote methods for.

<P>This is not too appealing in such a simple example, but if we consider
how this is used in a real application framework, it is a very useful construct.
The writer of an application framework will write a complete program that
does all of the necessary housekeeping and windows maintenance chores and
partition it in a number of virtual methods much like we did here. Of course,
the framework will be composed of a large body of code to do all of those
chores. In much the same manner that we picked which parts of this little
display program we wished to use, and which to override, we pick those
parts of the framework that we wish to keep as is and override those parts
that we wish change. A large body of code is therefore already written
for us and ready for our use.

<P>The application framework can include many other preprogrammed functions
ready for our use, such as editor code for edit windows, data verification
code for dialogue windows, and ready to use message window code. You will
find it to be a very rewarding study to spend time examining the capabilities
of one or more of the commercially available application frameworks.

<P><B>A PURE VIRTUAL FUNCTION</B>

<P>Example program ------> <B><A HREF="APPFRAM2.CPP">APPFRAM2.CPP</A></B>

<P>The example program named APPFRAM2.CPP illustrates a pure virtual function.
A pure virtual function is declared by assigning the value of zero to the
function as illustrated in line 10. A class containing one or more pure
virtual functions cannot be used to define an object. The class is therefore
only useful as a base class to be inherited into a useable derived class.
It is sometimes called an abstract class.

<P>Every derived class must include a function for each pure virtual function
that is inherited from the base class if it will be used to create an object.
This assures that there will be a function available for each call and
none will ever need to be answered by the base class, which it cannot do
since it does not have an implementation for a pure virtual function. You
cannot create an object of any class which contains one or more pure virtual
functions, because there is nothing to answer a message if one is sent
to the pure virtual method. The compiler will enforce the two rules mentioned
in this paragraph. If a class inherits an abstract class without providing
an override for the pure virtual function, then it too becomes an abstract
class and cannot be used to define an object.

<P>You will notice that the present example uses an abstract base class
which makes it illegal to use an object of the base class as we did in
the last example program. For that reason, some of the main program is
commented out.

<P>You will find abstract classes used in many commercially available libraries
and in application frameworks. Be sure to compile and execute this program,
then make some modifications to see what the compiler indicates if you
try to violate some of the rules we have delineated here.

<P><B>PROGRAMMING EXERCISES</B>
<OL>
<LI>
Add a new class named <B>consultant </B>to the files named SUPERVSR.H and
SUPERVSR.CPP, then add code to EMPLOYE2.CPP to exercise the new class.
Note that you do not need to recompile the linked list class in order to
execute the new code and use the new class. Even without recompiling the
linked list class it is capable of storing and passing the new class of
data provided of course that the new class is referred to using a pointer
to the parent class.</LI>
</OL>
<A HREF="chap12.htm">Advance to Chapter 12</A>

<P><A HREF="cpplist.htm">Return to the Table of Contents</A>
</BODY>
</HTML>