home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16176 < prev    next >
Encoding:
Text File  |  1992-11-12  |  2.0 KB  |  37 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!secapl!Cookie!frank
  3. From: frank@Cookie.secapl.com (Frank Adams)
  4. Subject: Re: Discriminating Variant Records Without switch() ??
  5. Message-ID: <1992Nov12.220050.94489@Cookie.secapl.com>
  6. Date: Thu, 12 Nov 1992 22:00:50 GMT
  7. References: <BAB.92Nov10073324@se39.wg2.waii.com> <1992Nov11.144253.26415@bnr.ca> <BAB.92Nov12074430@se39.wg2.waii.com>
  8. Organization: Security APL, Inc.
  9. Lines: 26
  10.  
  11. In article <BAB.92Nov12074430@se39.wg2.waii.com> bab@se39.wg2.waii.com (Brian Button) writes:
  12. >->"Matthew" == Matthew Holiday <holiday@bnr.ca> writes:
  13. >   Matthew> switch statement! :-) There ought to be a convenient way
  14. >   Matthew> to create objects from network messages, i.e., some way to
  15. >   Matthew> register message types and their matching class types,
  16. >   Matthew> such that for every incoming message, its body (an array
  17. >   Matthew> of bytes) gets turned into the correct object, which would
  18. >   Matthew> be derived from a root generic message object.
  19. >
  20. >There is such a way using factory classes such as the RogueWave
  21. >RWFactory class. The problem I'm having is figuring out how to deal
  22. >with these objects after they are already created. Since there's no
  23. >common set of operations which are performed on each of the objects,
  24. >there is no set of methods which may be made virtual and overloaded.
  25. >Herein lies the problem. This seems to point towards using special
  26. >purpose code for each class, which would necessitate using a switch.
  27. >
  28. >Have I painted myself into a corner or is there some way out. How are
  29. >the rest of you OOP programmers dealing with cases like this?
  30.  
  31. You are obviously reading these all in one place, so you must be doing
  32. *something* with them.  Maybe just "handling" them -- which would suggest
  33. that the base class should have a virtual handle() method, which is
  34. implemented for each subclass to do whatever needs doing for that type of
  35. object.  There may not be any other commonality -- if there isn't, don't try
  36. to force it where it doesn't exist.
  37.