home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sw / componen / 155 < prev    next >
Encoding:
Internet Message Format  |  1992-11-06  |  2.2 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!sun-barr!olivea!decwrl!decwrl!apple!mumbo.apple.com!gallant.apple.com!wintermute.apple.com!user
  2. From: ksand@apple.com (Kent Sandvik )
  3. Newsgroups: comp.sw.components
  4. Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
  5. Message-ID: <ksand-051192155051@wintermute.apple.com>
  6. Date: 5 Nov 92 23:54:23 GMT
  7. References: <1992Oct29.182814.17630@den.mmc.com> <6597@dove.nist.gov> <1992Nov3.050919.8442@latcs1.lat.oz.au> <Bx56G1.8pr@cs.uiuc.edu> <jubo.720960526@rwthi3>
  8. Sender: news@gallant.apple.com
  9. Followup-To: comp.sw.components
  10. Organization: Apple
  11. Lines: 32
  12.  
  13. In article <jubo.720960526@rwthi3>, jubo@rwthi3.informatik.rwth-aachen.de >
  14. Right, if you assume inheritance=subtyping!
  15. > In "designing" this way you will loose control over your "architecture",
  16. > since most of the dependencies you introduce are not explicitely visible in
  17. > your interfaces. Ok, there are a lot of tools that help (e.g. browsers), but
  18. > to find the places of interest (i.e. which methods are executed) is a mess.
  19.  
  20. Well, as a former HW designer, and current OO programmer I have to make
  21. the statement that HW engineers don't subclass ICs, they define glue 
  22. electronics for combining the ICs for more functionality. If we find
  23. something resembling inheritance it would be programmatic IC circuits,
  24. but in this state we are really dealing with changing the internal
  25. states of the components concerning functionality, and the effect
  26. is very much limited to the black box (IC) itself.
  27.  
  28. I do think that one of the main issues is that we need to look at
  29. objects and classes from a more purist and simplified view, instead
  30. of building complex inheritance trees and speak about reuse of code
  31. using inheritance. Maybe we should limit out efforts into writing 
  32. reusable class components, and compromise concerning defining 
  33. huge inheritance tree systems. And let the functionality (complexity)
  34. appear from interaction between simple but powerful entities. Mixin
  35. classes, for instance.
  36.  
  37. In other words, I applaude the current thinking of looking at
  38. smaller, self-contained modules as the possible mean of designing
  39. systems.
  40.  
  41. Kent
  42. -------------------
  43. Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
  44. DISCLAIMER: Private activities on the Net.
  45.