home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12340 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.8 KB
  1. Path: sparky!uunet!mcsun!sunic!hagbard!loglule!jbn
  2. From: jbn@lulea.trab.se (Johan Bengtsson)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Downcasting (was: Re: run-time type checking)
  5. Message-ID: <4823@holden.lulea.trab.se>
  6. Date: 14 Aug 92 10:32:18 GMT
  7. References: <9222715.29197@mulga.cs.mu.OZ.AU>
  8. Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
  9. Lines: 58
  10. X-Newsreader: Tin 1.1 PL4
  11.  
  12. fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  13. : jbn@lulea.trab.se (Johan Bengtsson) writes:
  14. : 
  15. : >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  16. : >:
  17. : >:    class Base { //....
  18. :         virtual operator Derived1*() { return 0; }
  19. :         virtual operator Derived2*() { return 0; }
  20. : >:    };
  21. : >:Now what does this do? Well, it preserved th open/closed principle
  22. : >:and encapsulation and the explicit interfaces principle.
  23. : >
  24. : >What if someone using your classes decides to add a Derived3 class
  25. : >to which downcasting should be possible?  He must modifiy your
  26. : >class Base, for which he may not have source code.
  27. : 
  28. : Yes, but that would be a change to the interface!
  29.  
  30.     I get your point.  I also agree that the above technique
  31.     is best (most efficient) when you have a limited set
  32.     of known derived classes.
  33.  
  34. : 
  35. : The whole point is that the ability to downcast a Base to a derived class
  36. : SHOULD be part of the interface. If you want to change the interface, then
  37. : of course you are going to need to modify the source code - this does not
  38. : violate the open/closed principle.
  39.  
  40.     I agree that unrestricted typecasting provides the ability to
  41.     cleanly extend the interface of a base class, into the interface
  42.     of any derived class.  Although I admit that in a way this does
  43.     break the "closedness" of the Base class interface, I don't think
  44.     it does so in a "bad" way.
  45.  
  46.     After all, inheritance allows us to break the "closedness"
  47.     of a base class' behaviour, by overriding virtual functions.
  48.  
  49.     The importance is that in neither case do you have to
  50.     intervene with the source or compiled code of the base
  51.     class to do what you want.  This is considered good
  52.     for behaviour (overriding virtuals), so why not also
  53.     for interfaces (unrestricted but safe downcasting)?
  54.  
  55.     To conclude:
  56.  
  57.     A base class intended for future inheritance (even by
  58.     other programmers) should support overriding behaviour
  59.     using virtual member functions, and should support
  60.     interface extension by runtime-checked, safe downcasting.
  61.  
  62.     This lessens the risk that future users without access to the
  63.     source code will get stuck when deriving from the base class.
  64.  
  65. -- 
  66. --------------------------------------------------------------------------
  67. | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  68. | jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
  69. --------------------------------------------------------------------------
  70.