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 myPublicInterface1() ;
void myPublicInterface1() ;

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]

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 myPublicInterface1() ;
void myPublicInterface1() ;

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

This has absolutely no value. Those functions are accesible anyway, you
know.

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?

No - because you do not reduce the number of public, virtual functions.

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?

This is not any better as base *b = new derived(...) will no longer compile.

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

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]

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 myPublicInterface1() ;
void myPublicInterface1() ;

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?

Because public inheritance should mean IS-A which implies that
you must provide at least as much if not more than the base class.

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?

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.

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

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]

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

 

[Phlip]

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

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

 

[Rob]

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

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]

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.

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]

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

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.]

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 myPublicInterface1() ;
void myPublicInterface1() ;

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

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<base*>(d)->virtualMethod1();
}

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

- No. of public virtual interfaces should be reduced as much as
possible

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

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

No, for the reasons cited above.

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?

If you do this, you can't hold a derived object in a base*. Is that what
you want?

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

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)]

(e-mail address removed) (qazmlp) might (or might not) have written
this on (or about) 31 Jan 2004 07:08:44 -0800, :

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 myPublicInterface1() ;
void myPublicInterface1() ;

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?

No, probably because it won't compile. You can't make a derivative
member less accessible than a base member.

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?

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*

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

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]

No, probably because it won't compile. You can't make a derivative
member less accessible than a base member.

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?

 

[Uncle Bob (Robert C. Martin)]

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

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

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]

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?

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:

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...").

 

[Dag Henriksson]

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?

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]

Actually, the original example does not compile.

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

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.

 

[Avner Ben]

...
I don't doubt that there are some compilers that will compile it; but
I thought it was illegal in the language...

To the best of my Knowledge, this is legal in C++. In fact I once New a
developer that made a whole methodology out of it. Bear in mind that if
the function is late-bound through a base pointer. Only the base access
control is Known.

This is not the only peculiarity in the C++ inheritance system. For
example, you can also change a default argument value in a virtual
function override. the default you get will depend upon the level of
pointer used (rather error prone).

Avner.

 

[Tsolak Petrosian]

Simple.

You are implementing a type and trying to hide it.
Why? You could not implement in at all in the first place.

If you need to change the definition of derived class's type, then
define another type.

If you need to partially implement the type, then implement the needed
methods and have others to be as stubs or throw an exception.

There is no other good reason to make virtual functions as private.

Tsolak Petrosian

 

[Nick Hounsome]

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.

It is quite important that accessability is not considered until after name
lookup.
I think this is so that changing the accessability of a method wont break
client code.

 

[Robert C. Martin]

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?

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.
**********************************************

Live and learn. I could have sworn this was illegal. Perhaps it
used to be.

 

[Daniel T.]

"Dag Henriksson" <[email protected]> might (or might not)
have written this on (or about) Tue, 3 Feb 2004 09:43:19 +0100, :

"Uncle Bob (Robert C. Martin)" <[email protected]> skrev i
meddelandet
No, probably because it won't compile. You can't make a derivative
member less accessible than a base member.

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

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

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?

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.
**********************************************

Live and learn. I could have sworn this was illegal. Perhaps it
used to be.

It's illegal in Java, but not C++.