Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!brunix!sdm
From: sdm@cs.brown.edu (Scott Meyers)
Newsgroups: comp.lang.c++
Subject: Re: Message dispatching
Message-ID: <39275@brunix.UUCP>
Date: 9 May 90 16:35:40 GMT
Sender: news@brunix.UUCP
Reply-To: sdm@cs.brown.edu (Scott Meyers)
Organization: Brown University Department of Computer Science
Lines: 61

In article <3550@tymix.UUCP> roberts@lobot.Tymnet.COM (Michael Roberts) writes:
: I have a database of objects (all members of classes derived from a common
: base class).  Some of these objects are members of a text class.  That
: text class has methods to respond to editing messages.  Also in the
: database are version class objects.  Version objects each contain a
: pointer to a text class object, as well as data and methods for
: responding to versioning commands.  My application uses version class
: objects to provide the interface to the text class objects, and so
: protect them from arbitrary editing which does not adhere to versioning
: standards.

[stuff deleted]

: The version class performs protective services that amount to message
: routing and manipulation.  I have achieved this via a laborious process of
: duplicating each and every message that a contained object can respond to
: with a like-named method in the version class.  Almost all these version
: methods are identical in basic form: they check and update certain version
: data, then if conditions are met, send the appropriate editing message to
: the contained object.  By design, that message always has the same name as
: the version method itself.

I think you're going about this backwards.  Instead of having class Version
police the interface to class Text (and other classes), have class Text
(and the other classes) police its own interface, drawing on services
provided by class Version.  The easiest way to do this is to have Text be a
derived class of Version.  Then the only functions you have to write for
Version are those that truly apply to Version objects -- you don't need to
duplicate the functions of the Text objects.  Each of the Text functions,
in turn, is responsible for calling the appropriate Version function to
validate its actions.  For example:

    class VersionObject {
      protected:
        Boolean verifyEdit();
        ...
    };

    class TextObject: public VersionObject {
      public:
        void edit();
        ...
    };

    void TextObject::edit() {
      if (this->verifyEdit())
        // do the editing
      else
        // issue an error
    }

Class Version shouldn't have too many member functions if, as you imply,
most of the checking is pretty standard -- you just write a function for
each type of checking required.  An additional advantage of this approach
is that you can separate out the data in class Text that is primarily used
for validation and migrate it up into class Version.

Scott