home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3232 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  3.4 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!Sirius.dfn.de!chx400!bernina!neptune!santas
  2. From: santas@inf.ethz.ch (Philip Santas)
  3. Newsgroups: comp.object
  4. Subject: Re: O.M() versus M(O) notation
  5. Message-ID: <1992Aug17.224337.1226@neptune.inf.ethz.ch>
  6. Date: 17 Aug 92 22:43:37 GMT
  7. References: <1992Aug15.124149.28538@m.cs.uiuc.edu>> <PCG.92Aug16184526@aberdb.aber.ac.uk> <1992Aug16.212818.29943@m.cs.uiuc.edu>
  8. Sender: news@neptune.inf.ethz.ch (Mr News)
  9. Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
  10. Lines: 62
  11. Nntp-Posting-Host: spica.inf.ethz.ch
  12.  
  13.  
  14. In article <1992Aug16.212818.29943@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
  15. >
  16. >>johnson> An abstract class is much more than just an interface
  17. >>johnson> specification.  It also includes part of the implementation of
  18. >>johnson> the class, but it has some 'holes' in it that subclasses must
  19. >>johnson> fill in.  It is really a reusable design for subclasses, not an
  20. >>johnson> interface specification.  Of course, in languages without
  21. >>johnson> separate interface specifications, people use abstract classes
  22. >>johnson> to make a separate entity in their program that is just
  23. >>johnson> interface.
  24. >
  25. >The purpose of an abstract class is NOT supposed to be to represent
  26. >an interface.  An abstract class represents a skeleton for a class.
  27. >It is a class that is to be used ONLY by subclassing.  A subclass
  28. >designer creates a subclass by filling in the 'holes', i.e. by
  29. >"fleshing out" the skeleton.  It is true that C++ programmers will
  30. >create a class that is only interface, with no implementation at all,
  31. >but that is not the real purpose of an abstract class.  An abstract
  32. >class is implementation, not just interface.
  33.  
  34. I am sorry, but this clarification, does not make things clearer to me.
  35. If the abstract class "is NOT supposed to be to represent interface", 
  36. then how can it be "not just interface"? Does it represent interface after all?
  37. I think that your answer is important here since it seems to represent
  38. the whole (almost the whole) OO community in this discussion..
  39.  
  40. Concerning skeleton: is this including both interface and implementation?
  41. (given Piercarlo's definitions, with which I do not completely agree,
  42. but for the moment I do not have ready to present something less complicated)
  43.  
  44. >An abstract class defines some "abstract" or "deferred" methods
  45. >whose interface is defined, but whose implementation is not.
  46. >It also defines some "template" methods that are defined in terms
  47. >of the abstract methods.  Subclasses must provide an implementation
  48. >of each of the abstract methods, and then they can use the template
  49. >methods that they inherit.  This is a very important and common
  50. >design technique in object-oriented systems.  It would be just as
  51. >useful if languages separated interface from implementations.
  52.  
  53. If the abstract class _is_ implementation, then why _must_ the subclasses
  54. redefine the implementation? One has to choose what implemnetation is
  55. inherited where in the most general way.
  56.  
  57. Philip Santas
  58.  
  59.   "In an evolving universe those who stand still are really moving backwards"
  60. --------------------------------------------------------------------------------
  61. email: santas@inf.ethz.ch                 Philip Santas
  62. Mail: Dept. Informatik                Department of Computer Science
  63.       ETH-Zentrum              Swiss Federal Institute of Technology
  64.       CH-8092 Zurich                       Zurich, Switzerland
  65.       Switzerland
  66. Phone: +41-1-2547391
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.     
  75.