home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11451 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.4 KB  |  85 lines
  1. Path: sparky!uunet!cs.utexas.edu!rutgers!cmcl2!psinntp!psinntp!searchtech.com!johnb
  2. From: johnb@searchtech.com (John Baldwin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Refs to paper, how not to expose class implementation
  5. Keywords: type opacity, abstract data typing, messages
  6. Message-ID: <1992Jul22.230329.1912@searchtech.com>
  7. Date: 22 Jul 92 23:03:29 GMT
  8. Organization: Search Technology, Inc.
  9. Lines: 74
  10.  
  11.  
  12.    Hello, netters!
  13.  
  14.       I referred to a certain paper recently and now I somehow cannot find
  15.    it.  I don't remember the title nor the author --- just the content.
  16.    Hopefully, someone here will recognize it and be able to provide me the
  17.    reference.
  18.  
  19.  
  20.    -------------------------------------------------------------------------
  21.    SYNOPSIS OF ARTICLE:
  22.  
  23.       The general idea was that some classes, by their very nature, contain
  24.    certain information which the user must know it contains.  But often these
  25.    classes are implemented in such a way as to expose too much of their
  26.    implementation.
  27.  
  28.       For example:
  29.  
  30.  
  31.       class SomeType {
  32.      public:
  33.         .
  34.         .
  35.         bool     setStartTime(const Time& input);
  36.         bool     setEndTime(const Time& input);
  37.         .
  38.         .
  39.         bool     setSomeCondition( OtherType somevar );
  40.         .
  41.         .
  42.      private:
  43.         .
  44.         .
  45.         Time     startTime;
  46.         Time     endTime;
  47.         Foo      someCondition;
  48.         .
  49.         .
  50.       };
  51.  
  52.  
  53.       The proposed approach was to overload operator<< () and provide some
  54.    additional typing to differentiate similarly-typed values.  So instead
  55.    of writing:
  56.            myObj.setStartTime(begin);
  57.            myObj.setEndTime(finish);
  58.            myObj.setSomeCondition(neverOnSunday);
  59.  
  60.    ...which requires knowledge of the protocol of "set" methods for every
  61.    class, one would write:
  62.  
  63.            myObj << StartTime(begin);
  64.            myObj << EndTime(finish);
  65.            myObj << neverOnSunday;
  66.  
  67.    -------------------------------------------------------------------------
  68.  
  69.  
  70.       Does the above synopsis sound like a paper you've read in the last
  71.    year or so?  If so, please EMAIL to johnb@searchtech.com.  Please don't
  72.    flood the net with responses or inquiries.  If there's sufficient
  73.    interest, I'll post the reference if/when I get it.
  74.  
  75.  
  76.    THANKS!
  77.  
  78.  
  79.  
  80. -- 
  81. John Baldwin                                        johnb@searchtech.com
  82. Search Technology, Inc.                             uupsi!srchtec!johnb
  83. 4725 Peachtree Corners Cir., Ste 200                johnb@srchtec.uucp
  84. Norcross, Georgia  30092
  85.