home *** CD-ROM | disk | FTP | other *** search
/ Shareware 1 2 the Maxx / sw_1.zip / sw_1 / PROGRAM / CPTUTT22.ZIP / CHAP11.TXT < prev    next >
Text File  |  1992-01-20  |  16KB  |  350 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                                                        Chapter 11
  8.                                            MORE VIRTUAL FUNCTIONS
  9.  
  10. This chapter will actually be a continuation of the topics covered
  11. in the last chapter but this will be a fuller explanation of what
  12. virtual functions are and how they can be used in a program.  We
  13. will present a simple database program with a virtual function to
  14. show how it can be used, then we will go on to illustrate a more
  15. complex use of the virtual function in a manner that finally
  16. illustrates its utility and reason for existence.
  17.  
  18.  
  19. HOW TO START AN OOP PROJECT
  20. _________________________________________________________________
  21.  
  22. The observant student will notice that we begin our use of object
  23. oriented programming by identifying an object, or in this case a
  24. class of objects and even some subordinate objects, which we
  25. completely define.  When we get to the main program we then have
  26. a simple job with the remaining needs and they are completed using
  27. standard procedural programming techniques which we are familiar
  28. with.  This is the way to begin any object oriented programming
  29. project, by first identifying a few objects that can be separated
  30. conveniently from the rest of the code, programming them, then
  31. writing the main program.  It should be added that, for your first
  32. project using objects, do not try to make everything an object.
  33. Select a few objects and after gaining experience with object
  34. oriented programming techniques, use more objects on future
  35. projects.  Most programmers use too many objects for their first
  36. project and write very obtuse, unreadable code.
  37.  
  38.  
  39. THE PERSON HEADER FILE
  40. _________________________________________________________________
  41.  
  42. Examine the file named PERSON.H for the          ================
  43. definition file for the person class.  This          PERSON.H
  44. class definition should cause you no problem to  ================
  45. understand since there is nothing new here.  The
  46. only thing that should be mentioned about this
  47. class is that the protected mode is used for the variables so that
  48. they are readily available in the derived classes which will
  49. inherit this class.
  50.  
  51. THE PERSON IMPLEMENTATION
  52. _________________________________________________________________
  53.  
  54. The implementation for the person class is given here and it is a
  55. little strange in the way it is written and used.  The intent of
  56. this program is that the virtual method named display() in this
  57.  
  58.                                                         Page 11-1
  59.  
  60.                               Chapter 11 - More Virtual Functions
  61.  
  62.  
  63. file will never be used, but it is required by   ================
  64. the C++ compiler to be used for a default in        PERSON.CPP
  65. case some of the subclasses do not have this     ================
  66. function available.  In the main program we will
  67. be careful to never call this function due to
  68. the nature of the program we are writing.  Keep in mind that C++
  69. requires an implementation of all virtual functions even if they
  70. are never used.  In this case the message is obviously intended to
  71. be output as an error message.
  72.  
  73. Be sure to compile this program prior to going on to the next class
  74. definitions.
  75.  
  76.  
  77. THE SUPERVISOR HEADER
  78. _________________________________________________________________
  79.  
  80. The file named SUPERVSR.H contains the class     ================
  81. definitions for the three derived classes,          SUPERVSR.H
  82. supervisor, programmer, and secretary.  These    ================
  83. were all placed in a single file for two
  84. reasons.  The first reason is to simply
  85. illustrate to you that this can be done, and secondly, to allow
  86. some of the files to be combined on the disk and to require fewer
  87. compilations by you prior to executing the resulting program.  This
  88. is actually a good way to combine these files since they are all
  89. derived classes of a common class.  It is a matter of style or
  90. personal taste.
  91.  
  92. You will notice that all three of these classes contain a method
  93. named display() and all have the same return value of void, and all
  94. have the same number of parameters as the parent class's method of
  95. the same name.  All of this equality is required because they will
  96. all be called by the same call statement.  You will also notice
  97. that the other method in each class has the same name, but
  98. different numbers and types of formal parameters which prevents
  99. this method from being used as a virtual method.
  100.  
  101. The remainder of this file is simple and you should be able to read
  102. the code and understand it completely.  Once again, this file
  103. cannot be compiled or executed.
  104.  
  105.  
  106.  
  107. THE SUPERVISOR IMPLEMENTATION
  108. _________________________________________________________________
  109.  
  110. The file named SUPERVSR.CPP contains the         ================
  111. implementation for the three classes.  If you      SUPERVSR.CPP
  112. spend a little time studying the code, you will  ================
  113. find that each of the methods named init_data()
  114. simply initializes all fields to those passed in
  115. as the actual arguments in a very simple manner.
  116.  
  117.                                                         Page 11-2
  118.  
  119.                               Chapter 11 - More Virtual Functions
  120.  
  121.  
  122. The method named display(), however, outputs the stored data in
  123. different ways for each class since the data is so different in
  124. each of the classes.  Even though the interface to these three
  125. methods is identical, the actual code is significantly different.
  126. There is no reason code besides output could not have been used,
  127. but the output is so visible when the program is executed that it
  128. was chosen for this illustration.
  129.  
  130. This file should be compiled at this time in preparation for the
  131. next example program which will use all four classes as defined in
  132. these four files.
  133.  
  134.  
  135. THE FIRST CALLING PROGRAM
  136. _________________________________________________________________
  137.  
  138. The file named EMPLOYEE.CPP is the first program ================
  139. that uses the classes developed in this chapter,   EMPLOYEE.CPP
  140. and you will find that it is a very simple       ================
  141. program.
  142.  
  143. We begin with an array of ten pointers, each pointing to the base
  144. class.  As you recall from the last chapter, this is very important
  145. when using virtual functions, the pointer must point to the base
  146. class.  The pointers that will be stored in this array will all
  147. point to objects of the derived classes however.  When we use the
  148. resulting pointers to refer to the methods, the system will choose
  149. the method at run time, not at compile time as nearly all of our
  150. other programs have been doing.
  151.  
  152. We allocate six objects in lines 16 through 39, initialize them to
  153. some values using the methods named init_data(), then assign the
  154. pointers to the members of the array of pointers to person.
  155. Finally, in lines 41 and 42, we call the methods named display()
  156. to display the stored data on the monitor.  You will notice that
  157. even though we only use one method call in line 42, we actually
  158. send messages to each of the three methods named display() in the
  159. subclasses.  This is true dynamic binding because if we were to
  160. change the values of some of the pointers in the array, we would
  161. then call different methods with the same pointers.
  162.  
  163. Be sure to compile and execute this program before continuing on
  164. in this chapter.  You will recall that the linking step requires
  165. you to combine several files in order to satisfy all system calls.
  166. After you have done that, we will use the same objects in another
  167. way to show how they can be reused.
  168.  
  169. A PURE VIRTUAL FUNCTION
  170. _________________________________________________________________
  171.  
  172. The pure virtual function is also available in the C++ toolbox of
  173. possible constructs.  You can use a pure virtual function in the
  174.  
  175.                                                         Page 11-3
  176.  
  177.                               Chapter 11 - More Virtual Functions
  178.  
  179. present example program by changing line 10 of PERSON.H to read as
  180. follows;
  181.  
  182.      virtual void display(void) = 0;
  183.  
  184. You must then eliminate PERSON.CPP from the project or make
  185. sequence.  An implementation for a pure virtual function cannot
  186. exist in the base class.
  187.  
  188. Every derived class must include a function for each pure virtual
  189. function which is inherited into the derived class.  This assures
  190. that there will be a function available for each call and none will
  191. ever need to be answered by the base class.  You are not permitted
  192. to create an object of any class which contains one or more pure
  193. virtual functions because there is nothing to answer a message if
  194. one is sent to the pure virtual method.  The compiler will enforce
  195. the two rules mentioned in this paragraph.
  196.  
  197.  
  198.  
  199. THE LINKED LIST CLASS
  200. _________________________________________________________________
  201.  
  202. Examination of the file named ELEMLIST.H will    ================
  203. reveal the definition of two more classes which     ELEMLIST.H
  204. will be used to build a linked list of employees ================
  205. to illustrate a more practical way to use the
  206. dynamic binding we have been studying in this
  207. chapter.
  208.  
  209. The two classes were put in the same file because they work
  210. together so closely and neither is of much value without the other.
  211. You will notice that the elements of the linked list do not contain
  212. any data, only a pointer to the person class that we developed for
  213. the last program, so that the linked list will be composed of
  214. elements of the person class without modifying the class itself.
  215.  
  216. There are two interesting constructs used here that must be pointed
  217. out before going on to the next program.  The first is the partial
  218. declaration given in line 8 which allows us to refer to the class
  219. named employee_list before we actually define it.  The complete
  220. declaration for the class is given in lines 22 through 29.  The
  221. second construct of interest is the friend class listed in line 17
  222. where we give the entire class named employee_list free access to
  223. the variables which are a part of the employee_element class.  This
  224. is necessary because the method named add_person() must access the
  225. pointers contained in employee_element.  We could have defined an
  226. additional method as a part of employee_element and used this
  227. method to refer to the pointers but it was felt that these two
  228. classes work so well together that it is not a problem to open a
  229. window between the classes.  We still have complete privacy from
  230. all other programs and classes declared as parts of this program.
  231.  
  232.  
  233.                                                         Page 11-4
  234.  
  235.                               Chapter 11 - More Virtual Functions
  236.  
  237.  
  238. Note that the single method included in the employee_element class
  239. is implemented in inline code.  Two of the methods of employee_list
  240. are still open so we need an implementation for this class.
  241.  
  242.  
  243. THE LINKED LIST IMPLEMENTATION
  244. _________________________________________________________________
  245.  
  246. The file named ELEMLIST.CPP is the               ================
  247. implementation for the linked list classes and     ELEMLIST.CPP
  248. should be self explanatory if you understand how ================
  249. a singly linked list operates.  All new elements
  250. are added to the end of the current list.  This
  251. was done to keep it simple but a sorting mechanism could be added
  252. to sort the employees by name if desired.
  253.  
  254. The method to display the list simply traverses the list and calls
  255. the method named display() in line 30 once for each element of the
  256. list.
  257.  
  258. It is important for you to take notice that in this entire class,
  259. there is no mention made of the existence of the three derived
  260. classes, only the base class named person is mentioned.  The linked
  261. list therefore has no hint that the three subclasses even exist,
  262. but in spite of that, we will see this class send messages to the
  263. three subclasses as they are passed through this logic.  That is
  264. exactly what dynamic binding is, and we will have a little more to
  265. say about it after we examine the calling program.
  266.  
  267.  
  268.  
  269. THE LINKED LIST IMPLEMENTATION
  270. _________________________________________________________________
  271.  
  272. At this time you should examine the final        ================
  273. example program in this chapter named              EMPLOYE2.CPP
  274. EMPLOYE2.CPP for our best example of dynamic     ================
  275. binding in this tutorial, yet the program is
  276. kept very simple.
  277.  
  278. This program is very similar to the example program named
  279. EMPLOYEE.CPP with a few changes to better illustrate dynamic
  280. binding.  In line 7 we declare an object of the class employee_list
  281. to begin our linked list.  This is the only copy of the list we
  282. will need for this program.  For each of the elements, we allocate
  283. the data, fill it, and send it to the linked list to be added to
  284. the list where we allocate another linked list element to point to
  285. the new data, and add it to the list.  The code is very similar to
  286. the last program down through line 40.
  287.  
  288. In line 43 we send a message to the display_list() method which
  289. outputs the entire list of personnel.  You will notice that the
  290. linked list class defined in the files named ELEMLIST.H and
  291.  
  292.                                                         Page 11-5
  293.  
  294.                               Chapter 11 - More Virtual Functions
  295.  
  296. ELEMLIST.CPP are never informed in any way that the subclasses even
  297. exist but they dutifully pass the pointers to these subclasses to
  298. the correct methods and the program runs as expected.
  299.  
  300. If you changed PERSON.H to use a pure virtual function, it will
  301. still work with this program just as we discussed earlier.
  302.  
  303.  
  304. WHAT GOOD IS ALL OF THIS
  305. _________________________________________________________________
  306.  
  307. Now that we have the program completely debugged and working,
  308. suppose that we wished to add another class to the program, for
  309. example a class named consultant because we wished to include some
  310. consultants in our business.  We would have to write the class of
  311. course and the methods within the classes, but the linked list
  312. doesn't need to know that the new class is added, so it does not
  313. require any changes in order to update the program to handle
  314. consultant class objects.  In this particular case, the linked list
  315. is very small and easy to understand, but suppose the code was very
  316. long and complex as with a large database.  It would be very
  317. difficult to update every reference to the subclasses and add
  318. another subclass to every list where they were referred to, and
  319. this operation would be very error prone.  In the present example
  320. program, the linked list would not even have to be recompiled in
  321. order to add the new functionality.
  322.  
  323. It should be clear to you that it would be possible to actually
  324. define new types, dynamically allocate them, and begin using them
  325. even while the program was executing if we properly partitioned the
  326. code into executable units operating in parallel.  This would not
  327. be easy, but it could be done for a large database that was
  328. tracking the inventory for a large retail store, or even for an
  329. airlines reservation system.  You probably have little difficulty
  330. understanding the use of dynamically allocated memory for data, but
  331. dynamically allocating classes or types is new and difficult to
  332. grasp, but the possibility is there with dynamic binding.
  333.  
  334.  
  335. PROGRAMMING EXERCISES
  336. _________________________________________________________________
  337.  
  338.  
  339. 1.   Add a new class named consultant to the files named SUPERVSR.H
  340.      and SUPERVSR.CPP, then add code to EMPLOYE2.CPP to exercise
  341.      the new class.  Note that you do not need to recompile the
  342.      linked list class in order to execute the new code and use the
  343.      new class.  Even without recompiling the linked list class it
  344.      is capable of storing and passing the new class of data
  345.      provided of course that the new class is referred to using a
  346.      pointer to the parent class.
  347.  
  348.  
  349.                                                         Page 11-6
  350.