home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 5080 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.2 KB
  1. Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!uwm.edu!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
  5. Message-ID: <harvey.728148390@regina>
  6. Date: 27 Jan 93 15:26:30 GMT
  7. References: <1993Jan25.093100@axion.bt.co.uk>
  8. Sender: news@opl.com
  9. Lines: 76
  10.  
  11. pkeddie@axion.bt.co.uk (Paul Keddie) writes:
  12.  
  13.  
  14. >...
  15. >1) Are 00 programs harder to maintain than normal functional programs?
  16.  
  17. IMO a well written OO program is much easier to maintain.
  18.  
  19. >2) Do maintainers need to adopt new approaches to maintenance for 00
  20. >   programs?. For example, I've found trying to track function calls can
  21.  
  22. Traditional practices dictate that an employees performance is measured by
  23. the bulk of code produced in a development cycle. Using traditional
  24. practices in OO development can lead to programs that are incapable of
  25. being maintained.
  26.  
  27. Once employers realize the folly (and some do!), they will let the
  28. developers spend more time designing, and so on with the
  29. obvious benefits. I am fortunate to have found such an employer.
  30.  
  31. Suppose a well written (and designed!) C++ program falls into your lap
  32. as a maintainer. The first thing to do IMO is to thoroughly understand
  33. the design. Maintaining OO (and C++) requires a more global understanding
  34. of the system than with C.
  35.  
  36. I think this is a result of the fact that well designed OO packages
  37. (class, whatever) tend to get reused over and over, so the end result
  38. is that fixing a line of code can have impact throughout the system.
  39.  
  40. >   lead to dead ends if you come to a call to 'Handle' in an event-driven
  41. >   program. Is my approach wrong?
  42.  
  43. IMO debugging an OO system is more tedious than traditional C. The key
  44. here is to have small unit tests for each package, class whatever. If
  45. there is suspicious behavior, go back to the unit tests first and see
  46. if they were comprehensive enough, also the unit tests might give
  47. you clues as to how the "live" system differs from the unit test. My bias
  48. is to use debugging as a last resort. This bias has served me well.
  49.  
  50. >3) Are there more difficulties because of C++ rather than the 00 paradigm?
  51.  
  52. Refer to the endless arguements on comp.lang.c++
  53.  
  54. >4) Is badly written C++, 00 programs worst than the equivalent C programs?
  55.  
  56. A badly written C++ program can be your worst nightmare. A well written
  57. C++ program is a dream to work with. C falls in between somewhere.
  58.  
  59. -------------------------
  60.  
  61. I've been using C++ since 1987-88, Modula-2 before that. I enjoy the
  62. C++ language, but understand peoples frustrations. I would never 
  63. go back though.
  64.  
  65. Once you get the hang of it, OO and C++ are *very* productive. The
  66. key (as many people will tell you) is:
  67.  
  68. 1. There is no substitute for up-front analysis and design
  69.  
  70. 2. There is no substitute for building quality in up-front
  71.  
  72. 3. There is no substitute for catering your standards toward
  73.    the people who will be maintaining your system.
  74.  
  75. -----------------------
  76.  
  77. If you turn out to have more questions specific to C++, you should
  78. move your post to comp.lang.c++
  79.  
  80.  
  81.  
  82. -- 
  83. ++harvey
  84. ===========================================================================
  85. internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
  86. voice/fax:      617-965-0220    /  617-965-7599
  87.