Herb Sutter: never make virtual functions public(!)
Author
I was reading Herb Sutter's new book, Exceptional C++ style, and found one of the Items on class design very interesting.
He suggests that for good design you would by default make virtual functions private. That would be by default. If a derived class really required access to the base virtual function then you could make it protected instead. But only if the design called for it. And you would never make the virtual function public. All public functions would be non-virtual.
There seems to be a lot of merit to this. I was wondering whether anyone else had read it and been struck by how much at odds this is with the 'normal' way of doing things, or am I just slow to catch on?
Edit: I think I've found the article that the Item was originally based upon.
[Edited by - petewood on September 13, 2004 8:51:18 AM]
Is he saying that you should use the template method if the public interface needs to make use of virtual functions?
Quote:Original post by antareus
Is he saying that you should use the template method if the public interface needs to make use of virtual functions?
Yep basically, i've read this aswell.
I think the conclusion to this comes from that fact that we usually encapsulate the variance/variant/variation provide an invariant interface, usually applied when data implementation varies. So i guess the same can be said for logic implementation, if you declare a virtual method in a type then implementation varies on sub-types there for it should also be encapsulated and provide an invariant inteface if needed.
Author
Quote:Original post by antareus
Is he saying that you should use the template method if the public interface needs to make use of virtual functions?
The template method pattern would use protected virtual functions. But if you're not using that pattern or similar then you are advised to make them private.
Unless it's a destructor of course, otherwise you wouldn't be able to create any objects.
this would be impossible to do with java interfaces and i think also with Objective-C protocols.
I don't see why it would be necessary for Objective-C, Java or even C#.
I see this pattern basically as a work-around for C++'s lack of a native interface language construct.
Then again, I might be wrong [smile].
I see this pattern basically as a work-around for C++'s lack of a native interface language construct.
Then again, I might be wrong [smile].
So, using the classic Shape example, it is suggested that the following class definitions are used:
That would be less efficent than using a public virtual function as it has a second layer of indirection.
Skizz
class Shape{public: void Draw (void) { draw_the_shape (); }private: virtual void draw_the_shape (void) = 0;}class Rect : public Shape{private: virtual void draw_the_shape (void) { // draw a rectangle }}That would be less efficent than using a public virtual function as it has a second layer of indirection.
Skizz
Quote:Original post by petewood
I was reading Herb Sutter's new book, Exceptional C++ style, and found one of the Items on class design very interesting.
He suggests that for good design you would by default make virtual functions private.
(*snip*)
Hi,
Can you quote the rationale of this particular point ? I'm really interested since I can't see why it is so good (and, you are right, I do not own the book - but I asked my employer to buy it some weeks ago). When I want to have an animal screaming, why should I avoid to make the "scream" method public ? It sounds weird to me :|.
Regards,
(edit : posted that at the same time than Skizz. Can't be just a matter of efficiency - I believe micro-code efficiency is not the goal of such a rather important design consideration. And (from snk_kid) I don't see the point of having a constant interface without virtual functions - If my animal finnaly don't scream then what's the point of having a "scream" method, either virtual or non-virtual ? - Yours,).
Quote:Original post by darookie
I don't see why it would be necessary for Objective-C, Java or even C#.
I see this pattern basically as a work-around for C++'s lack of a native interface language construct.
Then again, I might be wrong [smile].
Its not a pattern (unless your talking about template method) what Herb's talking about i think is more of an observation.
If you really wonted to do the same in java then you would have to use an abstract class instead, also you can write interface types in c++ e.g.
template < typename T >struct Clonable { virtual T* clone(const T&) = 0; virtual ~Cloneable() = 0;};template < typename T >Cloneable<T>::~Cloneable() {}its just that the compiler is not gonna say anything if you do give a default implementation.
Quote:Original post by petewood
I was reading Herb Sutter's new book, Exceptional C++ style, and found one of the Items on class design very interesting.
He suggests that for good design you would by default make virtual functions private. That would be by default. If a derived class really required access to the base virtual function then you could make it protected instead. But only if the design called for it. And you would never make the virtual function public. All public functions would be non-virtual.
There seems to be a lot of merit to this. I was wondering whether anyone else had read it and been struck by how much at odds this is with the 'normal' way of doing things, or am I just slow to catch on?
I am more interested in why he is suggesting this (His thinking behind it, why he consider it to be good style?) Personally, I consider it good style to hide anything that users of that class have no use for.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
