The linked list implementation

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 a sorting mechanism could be added to sort the employees by name if desired.

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

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, only the base class named person 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.

The linked list implementation

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

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 declare an object of the class employee_list 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.

In line 43 we send a message to the display_list() 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.

If you changed PERSON.H to use a pure virtual function, it will still work with this program just as we discussed earlier.

What good is all of this?

Now that we have the program completely debugged and working, suppose that we wished to add another class to the program, for example a class named consultant because we wished to include some consultants in our business. 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 does not require any changes in order to update the program to handle consultant 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.

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.