Is there a good reason not to use publicly available virtual methods?

Question

Is there a good reason not to use publicly available virtual methods?

I read somewhere that we should avoid using publicly available virtual methods, but I want to confirm from experts if this is a valid statement?

Answer 1

For a good and stable API design, a non-virtual interface is a good idiom.

I am going to refer to the existing good literature on this subject:

• Herb Sutter: http://www.gotw.ca/publications/mill18.htm
• Additional idioms C ++ / Non_Virtual_Interface

See also these great answers:

• What is the meaning of a private pure virtual function?
• Automatically call a C ++ base class method
• Best way to declare an interface in C ++ 11
• How to ensure that virtual method calls extend down to the base class?
• What is the advantage of this indirect function call?

(Sumant Tambe has an intriguing Design Destination matrix on his blog, which has a few more bits of design intent.)

Answer 2

Performing virtual functions that are not publicly available allows the base class to create a protocol around them. If nothing else, this can be used for some accounting / profiling, requiring tools only the base class. The common interface of the base class can be the inline function, which simply forwards the virtual functions. Unfortunately, restrictions can be relaxed in derived classes, i.e. A derived class can give open access to the virtual function from the base class.

In fact, there is another important reason for creating virtual protected functions: when overloading virtual functions (for example, do_put() members in std::num_put<...> ), it is easy to accidentally hide other overloads when overriding only one function. When virtual functions are both a setup point and a call interface, this can easily lead to unexpected behavior. When the functions are virtual protected , it becomes clear that the calling interface and the setting interfaces are actually different, and the problem can be avoided even by using the derived class directly. virtual functions probably want to be protected to allow overriding functions to call the default implementation from the base class. If there is no default implementation, the virtual function can also be private .

This answer discusses why virtual functions should not be public . If you must have virtual functions, first of all, this is a separate question with a somewhat non-trivial answer.

Answer 3

One thing that comes to my mind - not using publicly available virtual methods makes it easy to separate the class interface from the implementation. Say you provide a public method:

 public: virtual void DoSth() { } 

After a while, a change will be introduced that requires initialization and completion of the base class before doing anything. If you have already received several classes from your class, you will have to change their implementation. But if you wrote it like this:

 protected: virtual void InternalDoSth() { } public: void DoSth() { InternalDoSth(); } 

This will only be a matter of changing the DoSth implementation:

 public: void DoSth() { InitializeSth(); InternalDoSth(); FinalizeSth(); } 

Creating two-level virtual functions is very cheap and provides you with an extra layer that allows you to easily control how the virtual method is called in the future.