Jump to content
  • Advertisement
Sign in to follow this  
petewood

Herb Sutter: never make virtual functions public(!)

This topic is 5146 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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].

Share this post


Link to post
Share on other sites
So, using the classic Shape example, it is suggested that the following class definitions are used:

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

Share this post


Link to post
Share on other sites
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,).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!