home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 5108 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  5.0 KB
  1. Path: sparky!uunet!ukma!darwin.sura.net!spool.mu.edu!hri.com!opl.com!regina!harvey
  2. From: harvey@opl.com (Harvey Reed)
  3. Newsgroups: comp.object
  4. Subject: Re: Maintenance and OO -- the problems of C++
  5. Message-ID: <harvey.728259672@regina>
  6. Date: 28 Jan 93 22:21:12 GMT
  7. References: <1993Jan25.093100@axion.bt.co.uk> <harvey.728148390@regina> <24715@alice.att.com> <C1JquC.K4v@panix.com>
  8. Sender: news@opl.com
  9. Lines: 116
  10.  
  11. fhd@panix.com (Frank Deutschmann) writes:
  12. >In <harvey.728148390@regina> harvey@opl.com (Harvey Reed) writes:
  13. >>pkeddie@axion.bt.co.uk (Paul Keddie) writes:
  14.  
  15. [NOTE:] please no smalltalk lover flames...
  16.  
  17. [NOTE:] IMO the choice of a language (particularly C++) has a lot
  18. to do with economic forces, not technical forces. The original post
  19. (from Paul) was talking about OO, but did mention C++, so the thread
  20. gets involved with that line of thought. If we keep discussing
  21. C++ program maintainance specifically (and I'm happy to do so!) we may want to 
  22. move this to comp.lang.c++ where there are similar dicussions about
  23. maintainance (and the corresponding embers and flames...)
  24.  
  25.  
  26. >>>1) Are 00 programs harder to maintain than normal functional programs?
  27. >                            ^^^^^^^^^^
  28. >I assume that PKeddie really meant traditional structured programs.
  29.  
  30. >>[...]
  31. >>Maintaining OO (and C++) requires a more global understanding
  32. >>of the system than with C.
  33. >>[...]
  34. >>so the end result
  35. >>is that fixing a line of code can have impact throughout the system.
  36. >>[...]
  37. >>IMO debugging an OO system is more tedious than traditional C.
  38.  
  39. >Isn't this exactly the OPPOSITE of what the goals of OO are?
  40. >[...]
  41. >The major flaw of C++ which causes the rippling change effect is that
  42. >C++'s requirement for strong type checking leads to heavy base
  43. >classes, while the Smalltalk/CLOS approach leads to lightweight super
  44. >[...]
  45.  
  46. I guess that's the difference between static type checking
  47. (C++), and more of a run-time environment (SmallTalk). I
  48. don't know if I would call it a flaw, it's just the approach
  49. that was taken.
  50.  
  51. >(As an aside, it would seem to me that this problem would prevent any
  52. >sort of mathematical model of OO from covering both Smalltalk/CLOS and
  53. >C++ environments.  In other words, while we may talk about all of
  54. [...]
  55.  
  56. I'm no expert here, but I'm sure there is a common subset that could
  57. apply to both.
  58.  
  59. >This problem is the dirrect cause of maintainence headaches: to add
  60. >behavior, the maintainer needs to chase inheritance towards the
  61. [...]
  62.  
  63. Well... I think of it as a challenge...
  64.  
  65. [...]
  66. >is the pointer to member: with the introduction of this special type,
  67. >C++ has created a pointer which is address arithmetic incompatabile
  68. >with other pointers.  This is not a good situation!
  69. [...]
  70.  
  71. I believe the stated position of those who would defend C++
  72. is that a pointer to a member is definately NOT a pointer,
  73. so the above doesn't apply. But, that's not to say that such
  74. notions add to the clarity of C++ terminology.
  75.  
  76. -----------------------------------
  77.  
  78. >IMO, these problems lead not only to maintainence problems, but also
  79. >prevent the original goals of OO: simplified systems maintainence to
  80. >keep up with evolving systems needs, and reuse of completed
  81. >development effort.
  82.  
  83. Again, I am sympathetic to your concerns. However I have built
  84. many large C++ systems, and find the process pretty easy to deal
  85. with... provided you and your team-mates have DISCIPLINE!
  86. Not to knock SmallTalk lovers, but many of the arguements
  87. for SmallTalk revolve around the more dynamic nature of the
  88. language.
  89.  
  90. IMHO, if a domain problem has been thoroughly analyzed, and the
  91. design is attended to by experienced developers, then you CAN end
  92. up with a system that is easier to deal with than the equivalent
  93. average quality C system.
  94.  
  95. This requires that the churning of requirements and design
  96. decisions are kept to a minimum. I am NOT promoting waterfall
  97. process, I believe in (for quite a while now) the spiral
  98. process. However, the spiral has to be conducted in such
  99. a way as to spew out the chunks of design in such an order
  100. that they won't change a whole lot later. This is the hardest
  101. part for developers to get. This is where human experience
  102. comes into play.
  103.  
  104. Regardless of language, I would use the approach above by the way.
  105. Now, for C++ what you are left with is a system that is a bit
  106. more "brittle" than a smalltalk system, but is that so bad?
  107. A properly documented system is maintainable.
  108.  
  109. I think that on the other side of the coin, folks used to
  110. smalltalk tend to make quicky-little-prototypes, and hope
  111. they scale. Folks used to C++ know that this is impossible
  112. to cope with in C++, so there is less of a tendency for this.
  113.  
  114. I don't think the "extremely-flexible-make-a-small-prototype-
  115. into-a-real-system" is one of the true promises of OO. And I don't
  116. think that large C++ systems violate promises of OO, but I DO THINK
  117. that it takes a lot more discipline in C++!!
  118.  
  119.  
  120.  
  121.  
  122. -- 
  123. ++harvey
  124. ===========================================================================
  125. internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
  126. voice/fax:      617-965-0220    /  617-965-7599
  127.