home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18281 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.7 KB  |  60 lines
  1. Newsgroups: comp.lang.c++
  2. From: nikki@trmphrst.demon.co.uk (Nikki Locke)
  3. Path: sparky!uunet!pipex!demon!trmphrst.demon.co.uk!nikki
  4. Subject: Re: Any inheritance experts out there
  5. Reply-To: nikki@trmphrst.demon.co.uk
  6. Distribution: world
  7. X-Mailer: cppnews $Revision: 1.30 $
  8. Organization: Trumphurst Ltd.
  9. Lines: 46
  10. Date: Mon, 21 Dec 1992 17:49:33 +0000
  11. Message-ID: <724985373snx@trmphrst.demon.co.uk>
  12. Sender: usenet@demon.co.uk
  13.  
  14. In article <4019@hpwala.wal.hp.com> friedman@hp-and.an.hp.com (joel friedman) writes:
  15. > I am writing device drivers for external memory devices. I currently
  16. > have to support two types devices (say A and B), but that number could
  17. > grow. The functions each device must support are common, but the
  18. > implementations used to provide them are quite different for each. The
  19. > type T below can be a char xor a short. The following template class
  20. > defines these core functions: 
  21. [ Template omitted. Oh, and do you think you could word-wrap your postings ?
  22. It makes them a lot easier to deal with. ]
  23.  
  24. > I want to design the hierarchy so I can easily add device C, D, E etc.
  25. > Here's the catch. How can I do this so that the application programs only
  26. > need to see the core_function class declaration; not the derived class
  27. > declarations for A or B. I need to enhance the core_functions class so
  28. > that the user can call a core_functions function, and it will be directed
  29. > to the implementation in the proper derived class (A or B). 
  30.  
  31. To start with, have a base class called something sensible and 
  32. understandable, like maybe "Device". Make the core functionality virtual. 
  33. Derive A, B (and maybe others) from it.
  34.  
  35. Now, who or what determines the type of device with which the application 
  36. is dealing ? I assume (because you don't want the application to know 
  37. about device types) that you have some function in your library which 
  38. determines the actual type of device which is connected, and the 
  39. application calls this. So, make the function retern a reference to a 
  40. Device. The function itself constructs an A, B (or C ...) and returns a 
  41. reference to it. The application continues to treat the returned Device 
  42. reference as a Device reference. It does not need to know what kind of
  43. device it is - it just calls virtual functions for the Device, and 
  44. everything works.
  45.  
  46. Example :
  47.  
  48. Device &determineWhatKindOfMouseWeHaveAndReturnAReferenceToIt() // :-)
  49. {
  50.     if(wierdAndWonderfulIoctlCall(ISTHISASERIALMOUSE))
  51.         return *new SerialMouse;
  52.     if(anotherStrangeHardwareCall(ISTHISABUSMOUSE))
  53.         return *new BusMouse;
  54.     return *new NotVeryUsefulKeyboardDeviceThatEmulatesAMouse;
  55. }
  56.  
  57. -- 
  58. Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
  59. trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
  60.