Should 'public virtual' always become 'private virtual'? & using private inheritance

[qazmlp]

class base
{
// other members
public:
virtual ~base()
{
}
virtual void virtualMethod1( )=0 ;
virtual void virtualMethod2( )=0 ;
virtual void virtualMethod3( )=0 ;
} ;


I derive a class from base. I want to make all the virtual functions
as private.
class derived : public base
{
// other members
public:
virtual ~derived()
{
}

void myPublicInterfa ce1() ;
void myPublicInterfa ce1() ;

private:
virtual void virtualMethod1( )=0 ;
virtual void virtualMethod2( )=0 ;
virtual void virtualMethod3( )=0 ;
} ;


I did the above considering the facts that
- in any case, the virtual functions will always be called through
the base class pointer only
- No. of public virtual interfaces should be reduced as much as
possible

Here are my questions:
1)
Can I consider this as a good design? If yes/no, why?

2)
How about
class derived : private base
{

}
instead of the above design, as anyway, all the inherited virtual
functions need to be made as private ?

Is this a correct design? If yes/no, why?


3)
What are the flaws in the above design and what do you suggest for
improvements?

[Peter Koch Larsen]

Re: Should 'public virtual' always become 'private virtual'? & using private inheritance


"qazmlp" <qazmlp1209@red iffmail.com> skrev i en meddelelse
news:db9bbf31.0 401310708.53fa2 70e@posting.goo gle.com...[color=blue]
> class base
> {
> // other members
> public:
> virtual ~base()
> {
> }
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
> } ;
>
>
> I derive a class from base. I want to make all the virtual functions
> as private.
> class derived : public base
> {
> // other members
> public:
> virtual ~derived()
> {
> }
>
> void myPublicInterfa ce1() ;
> void myPublicInterfa ce1() ;
>
> private:
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
> } ;[/color]

This has absolutely no value. Those functions are accesible anyway, you
know.
[color=blue]
>
>
> I did the above considering the facts that
> - in any case, the virtual functions will always be called through
> the base class pointer only
> - No. of public virtual interfaces should be reduced as much as
> possible
>
> Here are my questions:
> 1)
> Can I consider this as a good design? If yes/no, why?[/color]

No - because you do not reduce the number of public, virtual functions.[color=blue]
>
> 2)
> How about
> class derived : private base
> {
>
> }
> instead of the above design, as anyway, all the inherited virtual
> functions need to be made as private ?
>
> Is this a correct design? If yes/no, why?[/color]

This is not any better as base *b = new derived(...) will no longer compile.
[color=blue]
>
>
> 3)
> What are the flaws in the above design and what do you suggest for
> improvements?[/color]

Use this scheme instead:
class base
{
// other members
virtual void virtualMethod1( )=0 ;
virtual void virtualMethod2( )=0 ;
virtual void virtualMethod3( )=0 ;
public:
virtual ~base()
{
}
void method1() { virtualMethod1( );}
void method2() { virtualMethod2( );}
void method3() { virtualMethod3( );}

};

[Nick Hounsome]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance


"qazmlp" <qazmlp1209@red iffmail.com> wrote in message
news:db9bbf31.0 401310708.53fa2 70e@posting.goo gle.com...[color=blue]
> class base
> {
> // other members
> public:
> virtual ~base()
> {
> }
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
> } ;
>
>
> I derive a class from base. I want to make all the virtual functions
> as private.
> class derived : public base
> {
> // other members
> public:
> virtual ~derived()
> {
> }
>
> void myPublicInterfa ce1() ;
> void myPublicInterfa ce1() ;
>
> private:
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
> } ;
>
>
> I did the above considering the facts that
> - in any case, the virtual functions will always be called through
> the base class pointer only
> - No. of public virtual interfaces should be reduced as much as
> possible
>
> Here are my questions:
> 1)
> Can I consider this as a good design? If yes/no, why?
>[/color]

Because public inheritance should mean IS-A which implies that
you must provide at least as much if not more than the base class.
[color=blue]
> 2)
> How about
> class derived : private base
> {
>
> }
> instead of the above design, as anyway, all the inherited virtual
> functions need to be made as private ?
>
> Is this a correct design? If yes/no, why?
>[/color]

Depends - they can't both be right because either a derived IS-A base or not
and
that depends on what derived and base actually are.
[color=blue]
>
> 3)
> What are the flaws in the above design and what do you suggest for
> improvements?[/color]

It's not a design at all because it doesn't define what base and derived
actually are.
Until you decide that you cannot make sensible decisions about how to
implement them.

You must either tell us what they are supposed to be or rewrite your
question as
one of a purely language nature rather than design.

[Joe]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

Just curious......wh at is the advantage of lowering the number of public
virtual methods? Thanks


"Peter Koch Larsen" <pklspam@mailme .dk> wrote in message
news:HGPSb.8174 7$jf4.5236142@n ews000.worldonl ine.dk...[color=blue]
>
> "qazmlp" <qazmlp1209@red iffmail.com> skrev i en meddelelse
> news:db9bbf31.0 401310708.53fa2 70e@posting.goo gle.com...[color=green]
> > class base
> > {
> > // other members
> > public:
> > virtual ~base()
> > {
> > }
> > virtual void virtualMethod1( )=0 ;
> > virtual void virtualMethod2( )=0 ;
> > virtual void virtualMethod3( )=0 ;
> > } ;
> >
> >
> > I derive a class from base. I want to make all the virtual functions
> > as private.
> > class derived : public base
> > {
> > // other members
> > public:
> > virtual ~derived()
> > {
> > }
> >
> > void myPublicInterfa ce1() ;
> > void myPublicInterfa ce1() ;
> >
> > private:
> > virtual void virtualMethod1( )=0 ;
> > virtual void virtualMethod2( )=0 ;
> > virtual void virtualMethod3( )=0 ;
> > } ;[/color]
>
> This has absolutely no value. Those functions are accesible anyway, you
> know.
>[color=green]
> >
> >
> > I did the above considering the facts that
> > - in any case, the virtual functions will always be called through
> > the base class pointer only
> > - No. of public virtual interfaces should be reduced as much as
> > possible
> >
> > Here are my questions:
> > 1)
> > Can I consider this as a good design? If yes/no, why?[/color]
>
> No - because you do not reduce the number of public, virtual functions.[color=green]
> >
> > 2)
> > How about
> > class derived : private base
> > {
> >
> > }
> > instead of the above design, as anyway, all the inherited virtual
> > functions need to be made as private ?
> >
> > Is this a correct design? If yes/no, why?[/color]
>
> This is not any better as base *b = new derived(...) will no longer[/color]
compile.[color=blue]
>[color=green]
> >
> >
> > 3)
> > What are the flaws in the above design and what do you suggest for
> > improvements?[/color]
>
> Use this scheme instead:
> class base
> {
> // other members
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
> public:
> virtual ~base()
> {
> }
> void method1() { virtualMethod1( );}
> void method2() { virtualMethod2( );}
> void method3() { virtualMethod3( );}
>
> };
>
>
>[/color]

[Phlip]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

Joe wrote:
[color=blue]
> Just curious......wh at is the advantage of lowering the number of public
> virtual methods? Thanks[/color]

Liskov Substitution Principle gets easier to enforce - admitedly by
attrition, not necessarily thinking.

--
Phlip

http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

[Rob]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

"Joe" <jblack@wowmail .com> wrote in message
news:UXVSb.1654 7$gw3.7912626@n ews4.srv.hcvlny .cv.net...[color=blue]
> Just curious......wh at is the advantage of lowering the number of public
> virtual methods? Thanks
>[/color]

The most usual reason is that a public virtual function (virtually by
definition :-)
can be called by anyone, and the developer who overrides it must
therefore do things such as checking arguments to make sure they
are valid, and that the affected object remains in a valid state. And it
is easier to make a mistake and forget to check something.

Private virtual functions do not have that problem. They can only be
called by member functions or friends of the base class. This means
that the implementer of the base class can control the conditions under
which the virtual function is called. In this way, necessary preconditions
and postconditions can be checked and/or enforced.

[Rod Davison]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

On Sat, 31 Jan 2004 07:08:44 -0800, qazmlp wrote:
[color=blue]
> class base
> {
> // other members
> public:
> virtual ~base()
> {
> }
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
> } ;
>
>
> I derive a class from base. I want to make all the virtual functions as
> private.[/color]


Aside from not being allowed in some OO languages, it is always a bad
design decision to have a derived class remove an operation from the base
class definition, which is essentially what making a base class public
operation private in the derived class. Two reasons:

1. The derived class should not break the base class contract -- which is
what Liskov's principle is all about.

2. Derived classes should extend base classes, not reduce them -- this
suggests a potential design problem with the inheritance hierarchy.

Practical quick fix (but not necessarily a good one). Make the base class
virtual methods protected.

Also from a practical point of view, if your code compiles, are you really
sure that it does what think it does?

--
............... ............... ............... .....
The three most dangerous things are a programmer
with a soldering iron, a manager who codes, and a user who gets ideas.

Rod Davison - Critical Knowledge Systems Inc.

[Rod Davison]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

[color=blue]
> Also from a practical point of view, if your code compiles, are you really
> sure that it does what think it does?[/color]

Looking at the code I suspect that there will be a problem with the vtab
setup.
--
............... ............... ............... .....
If you lend someone $20, and never see that person
again, it was probably worth it.

Rod Davison - Critical Knowledge Systems Inc.

[Daniel T.]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

qazmlp1209@redi ffmail.com (qazmlp) wrote:
[color=blue]
> class base
> {
> // other members
> public:
> virtual ~base()
> {
> }
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
> } ;
>
>
> I derive a class from base. I want to make all the virtual functions
> as private.
> class derived : public base
> {
> // other members
> public:
> virtual ~derived()
> {
> }
>
> void myPublicInterfa ce1() ;
> void myPublicInterfa ce1() ;
>
> private:
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
> } ;
>
>
> I did the above considering the facts that
> - in any case, the virtual functions will always be called through
> the base class pointer only[/color]

Is this true? Will it always be true? Let's say I have a function with a
derived* and I want to call virtualMaethod1 .

void func( derived* d ) {
static_cast<bas e*>(d)->virtualMethod1 ();
}

It can be done, by why are you forcing the client to jump through the
extra hoop?

[color=blue]
> - No. of public virtual interfaces should be reduced as much as
> possible[/color]

You haven't reduced the number of virtual interfaces in 'derived' with
the above code.

[color=blue]
> Here are my questions:
> 1)
> Can I consider this as a good design? If yes/no, why?[/color]

No, for the reasons cited above.

[color=blue]
> 2)
> How about
> class derived : private base
> {
>
> }
> instead of the above design, as anyway, all the inherited virtual
> functions need to be made as private ?
>
> Is this a correct design? If yes/no, why?[/color]

If you do this, you can't hold a derived object in a base*. Is that what
you want?
[color=blue]
> 3)
> What are the flaws in the above design and what do you suggest for
> improvements?[/color]

I see two flaws in the above design. (a) you are attempting to make
private in derived that which cannot be made private because it is
public in the base class. (b) I don't know what in in 'other members' in
your base class, but I suspect I would not approve of whatever it is...

[Uncle Bob (Robert C. Martin)]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

qazmlp1209@redi ffmail.com (qazmlp) might (or might not) have written
this on (or about) 31 Jan 2004 07:08:44 -0800, :
[color=blue]
>class base
>{
> // other members
> public:
> virtual ~base()
> {
> }
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
>} ;
>
>
>I derive a class from base. I want to make all the virtual functions
>as private.
>class derived : public base
>{
> // other members
> public:
> virtual ~derived()
> {
> }
>
> void myPublicInterfa ce1() ;
> void myPublicInterfa ce1() ;
>
> private:
> virtual void virtualMethod1( )=0 ;
> virtual void virtualMethod2( )=0 ;
> virtual void virtualMethod3( )=0 ;
>} ;
>
>
>I did the above considering the facts that
> - in any case, the virtual functions will always be called through
>the base class pointer only
> - No. of public virtual interfaces should be reduced as much as
>possible
>
>Here are my questions:
>1)
>Can I consider this as a good design? If yes/no, why?[/color]

No, probably because it won't compile. You can't make a derivative
member less accessible than a base member.[color=blue]
>
>2)
>How about
>class derived : private base
>{
>
>}
>instead of the above design, as anyway, all the inherited virtual
>functions need to be made as private ?
>
>Is this a correct design? If yes/no, why?[/color]

This is better if the intent is for all the methods of derived to be
inaccessible to users of derived. However you also have to remember
that private inheritance prevents the implicit upcast from derived* to
base*
[color=blue]
>3)
>What are the flaws in the above design and what do you suggest for
>improvements ?[/color]

That depends on your intent. I think 2) is better than 1).



Robert C. Martin | "Uncle Bob"
Object Mentor Inc. | unclebob @ objectmentor . com
501 N. Riverside Dr.| Tel: (800) 338-6716
Suite 206 | Fax: (847) 775-8174 | www.objectmentor.com
| | www.XProgramming.com
Gurnee, IL, | Training and Mentoring | www.junit.org
60031 | OO, XP, Agile, C++, Java, C# | http://fitnesse.org

[Dag Henriksson]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o. b@objectmentor. com> skrev i
meddelandet news:6jmt101jb2 pifmnakvffribds tnuu434tv@4ax.c om...
[color=blue]
> No, probably because it won't compile. You can't make a derivative
> member less accessible than a base member.[/color]

What do you mean by that? You certainly can do:

class B
{
public:
virtual void foo() {}
};
class D : public B
{
private:
virtual void foo() {}
};

You must have meant something else, but what?

--
Dag Henriksson

[Uncle Bob (Robert C. Martin)]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

"Dag Henriksson" <dag_henriksson @hotmail.com> might (or might not)
have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
[color=blue]
>"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o. b@objectmentor. com> skrev i
>meddelandet news:6jmt101jb2 pifmnakvffribds tnuu434tv@4ax.c om...
>[color=green]
>> No, probably because it won't compile. You can't make a derivative
>> member less accessible than a base member.[/color]
>
>What do you mean by that? You certainly can do:
>
>class B
>{
>public:
> virtual void foo() {}
>};
>class D : public B
>{
>private:
> virtual void foo() {}
>};[/color]

Can you?

I don't doubt that there are some compilers that will compile it; but
I thought it was illegal in the language. I didn't think you could
use inheritance to restrict accessibility. Indeed, there is a special
mechanism (the using declaration) to make variables and functions that
are private in the base, public in a derivative.

It seems to me that making foo private in the derivative leads to
ambiguities. Consider:

D d;
d.foo();

Should the compiler complain that foo is private in D? Or should the
compiler implicitly cast the D& to a B& where foo is public?
It's been a long time since I checked this kind of thing though, so
maybe the language standard resolved this in a way that allowed it.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc. | unclebob @ objectmentor . com
501 N. Riverside Dr.| Tel: (800) 338-6716
Suite 206 | Fax: (847) 775-8174 | www.objectmentor.com
| | www.XProgramming.com
Gurnee, IL, | Training and Mentoring | www.junit.org
60031 | OO, XP, Agile, C++, Java, C# | http://fitnesse.org

[Rod Davison]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

On Tue, 03 Feb 2004 09:43:19 +0100, Dag Henriksson wrote:
[color=blue]
> "Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o. b@objectmentor. com> skrev
> i meddelandet news:6jmt101jb2 pifmnakvffribds tnuu434tv@4ax.c om...
>[color=green]
>> No, probably because it won't compile. You can't make a derivative
>> member less accessible than a base member.[/color]
>
> What do you mean by that? You certainly can do:
>
> class B
> {
> public:
> virtual void foo() {}
> };
> class D : public B
> {
> private:
> virtual void foo() {}
> };
>
> You must have meant something else, but what?[/color]

Actually, the original example does not compile. I tried it to see what
sort of error it might generate and my compiler got a problem with the
virtual function table. However, I think you missed the point of Robert
Martins comment.

It is not a syntactic rule of C++ that you should not make a baes class
public member private in a derived class, but an OOP principle that you
should not make the interface of a derived class a strict subset of the
interface of the base class. Violating this principle can result in two
undesirable outcomes:

1. Either code that does not compile like the original example because of
the compiler being unable to resolve function references.

2. Code that compiles, like your example, and produces bad results.

What are bad results? If we flesh out your classes like this:

class B
{
public:
virtual void foo() { cout <<"Base" << endl;}
};
class D : public B
{
private:
virtual void foo() { cout <<"Derived" << endl;}
};

so we can see which version is being called, then the code

int main() {
D *d = new D();
B *b = d;
b->foo();
// d->foo(); this line does NOT compile
}
}
produces the output "Derived" when it runs.

We have broken the interface of B (or D -- take your pick). We can have
broken encapsulation for d and we do not get the expected behavior. The
problem is that looking at the combination of inheritance and access
restriction means that the use of the base class pointer makes the
reference to foo() ambiguous. The compiler chose one option, I may have
intended another.

Java, on the other hand, has opted to make violating this OOP principle
impossible by enforcing it with a syntactic constraint -- if you tried to
compile this code in Java, it would not but would generate the error
"Cannot reduce the visibility of the inherited method from base".


I think Robert Martin's comment still stands but perhaps I would have
said:
[color=blue][color=green]
>> No, probably because it won't compile. You shouldn't make a derivative
>> member less accessible than a base member.[/color][/color]

I think the point to remember about C++, and any programming language for
that matter, is that just because the language allows you to do something
does not mean that it is good code. I would never allow any code like your
example to be used in any project I was working on because of the
potential for a down the road disaster. ("Gee, it always worked before
without any problems...").


--
............... ............... ............... .....
2 + 2 = 5 (for sufficiently large values of 2)

Rod Davison - Critical Knowledge Systems Inc.

[Dag Henriksson]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o. b@objectmentor. com> skrev i
meddelandet news:qc8v10pipv kv0ucrnp6qguq75 6sqf7apmu@4ax.c om...[color=blue]
> "Dag Henriksson" <dag_henriksson @hotmail.com> might (or might not)
> have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :
>[color=green]
> >"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o. b@objectmentor. com> skrev i
> >meddelandet news:6jmt101jb2 pifmnakvffribds tnuu434tv@4ax.c om...
> >[color=darkred]
> >> No, probably because it won't compile. You can't make a derivative
> >> member less accessible than a base member.[/color]
> >
> >What do you mean by that? You certainly can do:
> >
> >class B
> >{
> >public:
> > virtual void foo() {}
> >};
> >class D : public B
> >{
> >private:
> > virtual void foo() {}
> >};[/color]
>
> Can you?
>
> I don't doubt that there are some compilers that will compile it; but
> I thought it was illegal in the language. I didn't think you could
> use inheritance to restrict accessibility. Indeed, there is a special
> mechanism (the using declaration) to make variables and functions that
> are private in the base, public in a derivative.
>
> It seems to me that making foo private in the derivative leads to
> ambiguities. Consider:
>
> D d;
> d.foo();
>
> Should the compiler complain that foo is private in D? Or should the
> compiler implicitly cast the D& to a B& where foo is public?[/color]

The compiler should complain that foo is private in D.

I think the text and example in 11.6p1 makes this clear:
*************** *************** *************
11.6 Access to virtual functions

1 The access rules (clause 11) for a virtual function are determined by its
declaration and are not affected by the rules for a function that later
overrides it. [Example:

class B {
public:
virtual int f();
};

class D : public B {
private:
int f();
};

void f()
{
D d;
B* pb = &d;
D* pd = &d;
pb->f(); //OK: B::f() is public,
// D::f() is invoked
pd->f(); //error: D::f() is private
}

-end example] Access is checked at the call point using the type of the
expression used to denote the object for which the member function is called
(B* in the example above). The access of the member function in the class in
which it was defined (D in the example above) is in general not known.
*************** *************** *************** *

--
Dag Henriksson

[Dag Henriksson]

Re: Should 'public virtual' always become 'private virtual'? &amp; using private inheritance

"Rod Davison" <critsys@rogers .remove.com> skrev i meddelandet
[color=blue]
> Actually, the original example does not compile.[/color]

The only syntactic error I found in the original example was multiple
declarations of myPublicInterfa ce1().

I totally agree with Bob and you that the design is far from optimal. I was
just curious about what the syntactic error Bob pointed out was.

--
Dag Henriksson