home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18019 < prev    next >
Encoding:
Text File  |  1992-12-15  |  3.7 KB  |  84 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!slsvaat!josef!kanze
  3. From: kanze@us-es.sel.de (James Kanze)
  4. Subject: Re: Need help implementic data structures of generic objects
  5. In-Reply-To: cshaver@informix.com's message of 13 Dec 92 00:25:51 GMT
  6. Message-ID: <KANZE.92Dec15211535@slsvdnt.us-es.sel.de>
  7. Sender: news@us-es.sel.de
  8. Organization: SEL
  9. References: <1992Dec10.114636.16861@ucc.su.OZ.AU> <1992Dec11.233253.27540@informix.com>
  10.     <MATT.92Dec11162629@physics.berkeley.edu>
  11.     <1992Dec13.002551.778@informix.com>
  12. Date: 15 Dec 92 21:15:34
  13. Lines: 69
  14.  
  15. In article <1992Dec13.002551.778@informix.com> cshaver@informix.com
  16. (Craig Shaver) writes:
  17.  
  18.     [Quoted postings deleted...]
  19. |> This group seems to be biased against inheritance techniques in all cases.
  20.  
  21. I haven't noticed this, and I read the group pretty regularly.
  22.  
  23.     [Flame deleted...]
  24. |> It is obvious to me that you have a virtual function in the base class for 
  25. |> all functions that you need to use when dealing with 'Objects'.
  26.  
  27. But you don't know what all of the functions are that you will need.
  28.  
  29. Regrettably, I didn't save the original posting which started this
  30. thread, so I'm not completely sure what the original posters question
  31. was.  But deriving all classes from Object (or Root, or Top) is
  32. usually done in order to write a generic container class, which
  33. contains Object's (or whatever).
  34.  
  35. This is *not* the way to do it in C++.  The normal solution is to
  36. write the generic container class as a meta-class, and instantiate it
  37. for each type of container needed.  (In modern C++, you use templates
  38. to define a meta-class.  If you only have an older compiler, like I
  39. do, then you make do with the generic package.  Conceptually, they're
  40. the same thing, although at the implementation level...)
  41.  
  42. This idea didn't originate with C++; it is present in Ada.  But by
  43. combining it with classes and inheritance, it becomes far better than
  44. what Ada offered.
  45.  
  46. |> If you use a function on a class that is only restricted to a certain
  47. |> sub-tree of your inheritance structure, then you know what you are using,
  48. |> ergo, you should have used that type instead of 'Object'.
  49.  
  50. That's what we've been saying all along.  This seems an argument
  51. against your point of view.
  52.  
  53. |> IMHO, if you do not use inheritance, you are not doing OOP.  If you do
  54. |> not care, then you are just using C++ as a variation on C with no real
  55. |> benefit.
  56.  
  57. Well, I don't do OOP *just* to do OOP.  I use it as a means to an end.
  58. One of the means.  And I tend to use a lot of inheritance.  But not
  59. for the sake of inheritance, but because it corresponds to the model
  60. of what I'm doing.
  61.  
  62. If you take my String class, for example, you will find *no*
  63. inheritance.  Because the real world strings that I'm modelling are
  64. primitive types themselves, and not a type of anything else.  Adding
  65. inheritance (of what?) would just be excess bagage.
  66.  
  67. On the other hand, my container classes *do* inherit.  Because an
  68. associative array of String's (for example) is a type of an
  69. associative array.  There's inheritance in what I'm modelling, so
  70. there's inheritance in my program.
  71.  
  72. Since in most non-trivial programs, we have to consider several layers
  73. of abstraction in the modeled objects, most non-trivial programs will
  74. use inheritance.
  75.  
  76.     [I couldn't make much sense out of the rest of the posting; it
  77. sounded more like ranting and raving than any sort of argument.  So
  78. I've cut it.  Some one else can answer if they want to.]
  79. --
  80. James Kanze                             email: kanze@us-es.sel.de
  81. GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
  82. Conseils en informatique industrielle --
  83.                    -- Beratung in industrieller Datenverarbeitung
  84.