home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16598 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.0 KB  |  47 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!wupost!darwin.sura.net!sgiblab!rtech!odinba!karl
  3. From: karl@BofA.com (Karl Nicholas)
  4. Subject: Re: Complexity in the eyes of the beholder?
  5. Message-ID: <1992Nov19.221923.12282@BofA.com>
  6. Organization: Bank of America, Capital Products, RMTG #5906
  7. References: <1992Nov18.024553.24081@tagsys.com>
  8. Date: Thu, 19 Nov 92 22:19:23 GMT
  9. Lines: 36
  10.  
  11. In article <1992Nov18.024553.24081@tagsys.com> andrew@tagsys.com (Andrew Gideon) writes:
  12. >
  13. >On the other hand, I can grasp a simple class entirely:
  14. >interface and implementation.  When I "move up" a level,
  15. >I can drop the implementation information, and need
  16. >retain only the interface information.  The class becomes
  17. >a black box.
  18. >
  19. >To me, I achieve my goal (except when I violate my own
  20. >rules - which does happen more frequently than I like {8^).
  21. >But this coworker claims that the many levels are too
  22. >complex to follow.  In trying to understand a class, he
  23. >is forced to recurse too frequently and too far.
  24. >
  25.  But why is he recursing into the subclasses? It would seem
  26. to me that he should be taking the classes that he deals
  27. with for what they are, and not worry about how they work.
  28.  
  29.  This may not be of much help either because I guess
  30. I do not understand his point either. Perhaps you could help
  31. him with a class "flowchart", outlining subclasses and 
  32. the bullet point functionality of the class and a flowchart
  33. of hiearchy or inheritence.
  34.  
  35.   I think the tradeoff is speed of code verses modularity.
  36. many classes supports modularity, which from a systems
  37. standpoint is preferable, where larger classes supports
  38. speed of execution, which from a user standpoint is
  39. preferable. I try to incorporate as much modularity
  40. as possible until the speed for the user becomes a problem.
  41.  
  42. -- 
  43.  +---------------------------------------------------------------------------+
  44.  | Karl Nicholas   (415) 953-0409    | Beer is good food.  Food is not beer. |
  45.  | karl@BofA.COM   uunet!odinba!karl | *** BofA is not me, I am not BofA *** |
  46.  +---------------------------------------------------------------------------+
  47.