home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.eiffel
- Path: sparky!uunet!munnari.oz.au!metro!usage!syacus!ian
- From: ian@syacus.acus.oz.au (Ian Joyner)
- Subject: Re: Small methods ! Why ?
- Message-ID: <1992Jul29.025351.4001@syacus.acus.oz.au>
- Organization: ACUS Australian Centre for Unisys Software, Sydney
- References: <13303@ns-mx.uiowa.edu>
- Date: Wed, 29 Jul 1992 02:53:51 GMT
- Lines: 71
-
- rajar@herky.cs.uiowa.edu (Chandrashekar Rajaraman) writes:
-
- >Hi,
-
- >I came across the following sentence in a paper:
-
- >"Good object oriented programming style seems to encourage the
- >use of many small methods."
-
- >Why is this so ?
-
- >This programming style leads to code (and functionality)
- >that is widely dispersed. Therefore, a maintainer may have to
- >use sophisticated class browsers to understand the code even for
- >a fairly simple task, simply because it is widely dispersed.
-
- This sounds like a typical system written in C, where you have
- 100s of files to maintain, and the thing becomes a nightmare.
- It is true that analagously, lots of little methods will eventually
- become a maintenance problem. But I think this is counteracted
- by dividing the system into the larger class chunks. However,
- on the understandability and maintainability side, large routines
- are usually not understandable or maintainable. So breaking them
- down into smaller chunks with good clean interfaces between them
- will balance this problem.
-
- Another reason why you would want to break routines into smaller
- chunks is that it helps reusability. If you put more than one
- logical step into a routine, and you want to change one part
- of the functionality, you will have to override the whole lot.
- An example will make this clear.
-
- class A
-
- routine f
- seq1;
- seq2;
- end f;
- end A
-
- seq1, and seq2 are actually large sequences of program source. Now if
- you design a class B that inherits from A, you might find you have to
- modify the behaviour of the routine f in some way. On examination, you
- find that the functionality of the first part of f, ie seq1, is fine. But
- you need to change seq2. Now what you have to do is to rewrite the whole
- of seq1 in your redefinition of the f routine.
-
- Class A would have much better been written:
-
- class A
-
- routine f1
- seq1;
- end f1;
-
- routine f2
- seq2;
- end f2;
- end A
-
- This way, f1 would have been completely reusable as it was, and the
- redefinition in your new B class would have been localised to f2.
-
-
-
-
- --
- Ian Joyner ACUS (Australian Centre for Unisys Software) ian@syacus.acus.oz
- "Where is the man with all the great directions?...You can't imagine it,
- how hard it is to grow, Can you imagine the order of the universe?" ABWH
- Disclaimer:Opinions and comments are personal.
-