From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: ***
X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID,
	RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 114809,b87849933931bc93
X-Google-Attributes: gid114809,public
X-Google-Thread: fac41,b87849933931bc93
X-Google-Attributes: gidfac41,public
X-Google-Thread: 109fba,b87849933931bc93
X-Google-Attributes: gid109fba,public
X-Google-Thread: 1108a1,b87849933931bc93
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,b87849933931bc93
X-Google-Attributes: gid103376,public
X-Google-Thread: f43e6,b87849933931bc93
X-Google-Attributes: gidf43e6,public
From: "Risto Lankinen" <rlankine@us.oracle.com>
Subject: Re: What is wrong with OO ?
Date: 1997/01/16
Message-ID: <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>#1/1
X-Deja-AN: 210307391
references: <JSA.97Jan1181506@alexandria> <32D11FD3.41C6@wi.leidenuniv.nl>
 <E3pzy4.DHE@research.att.com> <01bbd23a$5b667cc0$LocalHost@christophe-leph>
 <E440xD.Lu0@ecf.toronto.edu>
content-type: text/plain; charset=ISO-8859-1
organization: Oracle Corporation
mime-version: 1.0
newsgroups: 
 comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng
Date: 1997-01-16T00:00:00+00:00
List-Id: <comp.lang.ada>


Hi!

Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
<E440xD.Lu0@ecf.toronto.edu>...
> 
>   Suppose a function does some important manipulation of private data
> members.  If it were virtual, then an heir class could override this
> function without ever calling it, and the data manipulation would never
> happen.  This could leave the object in an invalid state.  In C++, the
> only way to prevent this is by NOT declaring the function virtual.

This is true.  I would like to add, that if *both* the important data
manipulation *and* virtualness are needed, then there is still a way
to do it.  Here's how:

--------------------------------------------------
class Base
{
private:
   virtual void Function_imp()
   {
      // enforce preconditions
      // do 'Base' stuff
   }

public:
   void Function();
   {
      // do some important manipulation of private data
      Function_imp();
      // do more important manipulation of private data
      // enforce postconditions
};

class Derived : public Base
{
private:
   virtual void Function_imp()
   {
      // enforce preconditions
      // do 'Derived' stuff
   }
};
--------------------------------------------------

Then, any derived class can override the implementation, while
the public interface remains the same (hence the postconditions
are checked whenever the method is called, and the integrity of
the object becomes easier to maintain).

Note that *IF* the Java keyword 'final' was also in C++ (in Java
it means that a member function cannot be overridden, or a class
cannot be derived) then in the example, 'Base::Function()' could
itself be a virtual function derived from yet-another-base, but
then overridden and declared as 'final'.  Obviously this would
make it possible to stack postcondition checks by doing the same
'final'-trick to 'Derived::Function_imp()' and have it call, say,
private virtual 'Function_imp_imp()' that *its* derived classes
can override...

terv: Risto