home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / eiffel / 1012 < prev    next >
Encoding:
Text File  |  1992-07-29  |  2.6 KB  |  82 lines

  1. Newsgroups: comp.lang.eiffel
  2. Path: sparky!uunet!munnari.oz.au!metro!usage!syacus!ian
  3. From: ian@syacus.acus.oz.au (Ian Joyner)
  4. Subject: Re: Small methods ! Why ?
  5. Message-ID: <1992Jul29.025351.4001@syacus.acus.oz.au>
  6. Organization: ACUS Australian Centre for Unisys Software, Sydney
  7. References: <13303@ns-mx.uiowa.edu>
  8. Date: Wed, 29 Jul 1992 02:53:51 GMT
  9. Lines: 71
  10.  
  11. rajar@herky.cs.uiowa.edu (Chandrashekar Rajaraman) writes:
  12.  
  13. >Hi,
  14.  
  15. >I came across the following sentence in a paper:
  16.  
  17. >"Good object oriented programming style seems to encourage the
  18. >use of many small methods."
  19.  
  20. >Why is this so ?
  21.  
  22. >This programming style leads to code (and functionality)
  23. >that is widely dispersed.  Therefore, a maintainer may have to
  24. >use sophisticated class browsers to understand the code even for
  25. >a fairly simple task, simply because it is widely dispersed.
  26.  
  27. This sounds like a typical system written in C, where you have
  28. 100s of files to maintain, and the thing becomes a nightmare.
  29. It is true that analagously, lots of little methods will eventually
  30. become a maintenance problem. But I think this is counteracted
  31. by dividing the system into the larger class chunks. However,
  32. on the understandability and maintainability side, large routines
  33. are usually not understandable or maintainable. So breaking them
  34. down into smaller chunks with good clean interfaces between them
  35. will balance this problem.
  36.  
  37. Another reason why you would want to break routines into smaller
  38. chunks is that it helps reusability. If you put more than one
  39. logical step into a routine, and you want to change one part
  40. of the functionality, you will have to override the whole lot.
  41. An example will make this clear.
  42.  
  43. class A
  44.  
  45.     routine f
  46.        seq1;
  47.        seq2;
  48.     end f;
  49. end A
  50.  
  51. seq1, and seq2 are actually large sequences of program source.  Now if
  52. you design a class B that inherits from A, you might find you have to
  53. modify the behaviour of the routine f in some way.  On examination, you
  54. find that the functionality of the first part of f, ie seq1, is fine.  But
  55. you need to change seq2. Now what you have to do is to rewrite the whole
  56. of seq1 in your redefinition of the f routine.
  57.  
  58. Class A would have much better been written:
  59.  
  60. class A
  61.  
  62.    routine f1
  63.       seq1;
  64.    end f1;
  65.  
  66.    routine f2
  67.       seq2;
  68.    end f2;
  69. end A
  70.  
  71. This way, f1 would have been completely reusable as it was, and the 
  72. redefinition in your new B class would have been localised to f2. 
  73.  
  74.  
  75.      
  76.  
  77. -- 
  78. Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
  79. "Where is the man with all the great directions?...You can't imagine it,
  80.  how hard it is to grow, Can you imagine the order of the universe?" ABWH
  81. Disclaimer:Opinions and comments are personal.
  82.