home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18230 < prev    next >
Encoding:
Internet Message Format  |  1992-12-11  |  3.1 KB
  1. Xref: sparky comp.lang.c:18230 comp.lang.c++:17839 comp.misc:4553
  2. Path: sparky!uunet!spool.mu.edu!agate!ames!kronos.arc.nasa.gov!butch!netcomsv!ulogic!hartman
  3. From: hartman@ulogic.UUCP (Richard M. Hartman)
  4. Newsgroups: comp.lang.c,comp.lang.c++,comp.misc
  5. Subject: Re: What is Object Oriented Programming? Is C doomed?
  6. Message-ID: <730@ulogic.UUCP>
  7. Date: 11 Dec 92 22:37:36 GMT
  8. References: <Byx59B.5v5@news.cso.uiuc.edu> <1g40m9INNdhk@uwm.edu> <1992Dec9.151051.3628@mcs.drexel.edu>
  9. Followup-To: comp.lang.c
  10. Distribution: usa
  11. Organization: negligable
  12. Lines: 47
  13.  
  14. In article <1992Dec9.151051.3628@mcs.drexel.edu> tjhendry@mcs.drexel.edu (Jonathan Hendry) writes:
  15. >>Now you run into another problem.  Prewritten code is FIXED.  Code can't learn
  16. >>and modify itself and adapt.  Sorry you're out of luck.  Just put up, because
  17. >>modularity is supposed to be a Good Thing.  In reality, it's a Goof Thing.
  18. >
  19. >Ah, but here is where OOPS shines.If a supplied object doesn't do what you 
  20. >want it to do, just subclass it. That way, all you have to write is what you
  21. >want to add. You don't have to redo the whole thing. The subclass inherits
  22. >all the original class' behaviors and variables. You can add or change whatever
  23. >you want. WITHOUT changing the original code. I've written tons of subclasses
  24. >of NeXTSTEP objects, and I've never needed to change the original code 
  25. >(and couldn't if I wanted to)
  26.  
  27. Not always.  I tried subclassing NIH's LinkedList class and ran into
  28. tons of trouble due to the trick they pulled w/ the hidden dependancy
  29. between their .addFirst() and .add() member functions.  I had to reduplicate
  30. entire functions from their source code to properly handle something that
  31. SHOULD have been subclassable (is that a word???).
  32.  
  33. It is truly bizarre -- in the LinkedList::addFirst() member function
  34. there is a test: if the list is empty (size() == 0) they call LinkedList::add()
  35. which has special case code for adding the first node to an empty list!
  36.  
  37. This should be the other way around, if .add() to an empty list, call
  38. .addFirst() (if you need to do anything special at all).  As it was
  39. since .add() was virtual, I had to DUPLICATE their special purpose
  40. code in MY .add() routine because .addFirst() called MY .add() routine
  41. when it thought it couldn't handle the job!  This entailed gaining access
  42. to what should have been private member fields of their linked list class!
  43.  
  44. (note: the specifics of the problem may not be exact here -- I ran into
  45. this over a year and a half ago, kvetched, fixed it, and moved on.  I am
  46. pretty certain it was a hidden dependancy between these two routines as
  47. described, but it could be some variant thereof....)
  48.  
  49. OOP and C++ is NOT a "silver bullet", any more than "structured programming"
  50. was.  It is a new tool that gives us the potential for things that were
  51. more difficult before, but in and of itself does NOTHING.  That is the
  52. job of the software designer.  If it is done poorly, it is done poorly
  53. no matter what the language or paradigm.
  54.  
  55.         -Richard Hartman
  56.         hartman@ulogic.COM
  57.  
  58. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  59. Never speak in absolutes.  It will always lead to trouble.
  60.  
  61.