C++程序的设计机制1：NVI机制（Non-Virtual Interface ）

  C++程序的设计机制1：NVI机制（Non-Virtual Interface ）

在C++的程序设计中有一些设计开发的典型机制需要整理讨论，在此抛砖引玉，为自己做积累，请高人也多多指教。

1.简介

在标准C++库中我们可以看到这样的一个现象：

6个公有虚函数，并且都是std::exception::what()和其重载。

142个非公有虚函数。

这样设计的目的何在呢，为什么“多此一举”的把虚函数设置为非公有呢？

这就是NVI机制要求的：将虚函数声明为非公有，而将公有函数都声明为非虚——虚拟和公有选其一。

2.机制分析

程序员常常将基类中的虚函数公有化，来提供一个接口的定义（virtual的功劳）同时提供其实现（具体的一个实现）。

  1: class
 Base{

  2: public
:

  3:     virtual
 void
 Foo(int
){

  4:         cout<< "Base's Foo!
" << endl;

  5:     };

  6: };

问题就出在“同时”——一个定义了接口的形式，一个定义了默认的一个实现，显然这样的设计没有将接口定义和实现分来。在这个时候，我们可以使用模板方法模式 的思想：

  1: class
 Base{

  2: public
:

  3:     void
 Foo(){

  4:         DoFoo1();

  5:         DoFoo2();

  6:     }//use DoFooX()


  7: private
:

  8:     virtual
 void
 DoFoo1(){

  9:         cout << "Base's DoFoo1
" <<endl;

 10:     }

 11:     virtual
 void
 DoFoo2(){

 12:         cout << "Base's DoFoo2
" <<endl;

 13:     }

 14: };

 15: 

 16: class
 Derived: public
 Base{

 17: private
:

 18:     virtual
 void
 DoFoo1(){

 19:         cout << "Derived's DoFoo1
" << endl;

 20:     };

 21: };

函数Foo定义了接口的形式，而DoFooX()函数则实现了对Foo函数的行为定制，实现了接口定义和实现的分离 ，我们举一个例子来说明好处：如果我们希望在Foo中做一下CS（Critical Section）的加锁解锁控制：

若我们完成这样的接口与实现分离，那么我们的实现是在基类的接口处添加所需流程即可，子类不需要修改：

  1: class
 Base{

  2: public
:

  3:     void
 Foo(){

  4:         cout << "Locking
" << endl;

  5:         DoFoo1();

  6:         DoFoo2();

  7:         cout << "Unlocking
" << endl;

  8:     }//use DoFooX()


  9: private
:

 10:     virtual
 void
 DoFoo1(){

 11:         cout << "Base's DoFoo1
" <<endl;

 12:     }

 13:     virtual
 void
 DoFoo2(){

 14:         cout << "Base's DoFoo2
" <<endl;

 15:     }

 16: 

 17: };

 18: 

 19: class
 Derived: public
 Base{

 20: private
:

 21:     virtual
 void
 DoFoo1(){

 22:         cout << "Derived's DoFoo1
" << endl;

 23:     };

 24: };

若不实现接口与实现分离，则从基类到子类都需要修改：

  1: class
 Base{

  2: public
:

  3:     virtual
 void
 Foo(){

  4:         cout << "Locking
" << endl;

  5:         cout << "Base's Foo
" << endl;

  6:         cout << "Unlocking
" << endl;

  7:     }

  8: };

  9: 

 10: class
 Derived: public
 Base{

 11: public
:

 12:     virtual
 void
 Foo(){

 13:         cout << "Locking
" << endl;

 14:         cout << "Derived's Foo
" << endl;

 15:         cout << "Unlocking
" << endl;

 16:     };

 17: };

注意，当且仅当子类需要调用基类的虚函数时才将虚函数设置为protected（否则没有权限），并且NVI机制不适用于析构函数，对于析构函数， 如果设为公有则应该设置为虚拟（在允许多态删除的基类中），否则设置为私有或者protected的非虚拟形式（不含多态删除的基类中）。

带来的风险：

首先是FBC问题（Fragile Base Class ），下边是一个例子：

  1: class
 Set {

  2:     std::set<int
> s_;

  3:   public
:

  4:     void
 add (int
 i) {

  5:       s_.insert (i);

  6:       add_impl (i); // Note virtual call.


  7:     }

  8:     void
 addAll (int
 * begin, int
 * end) {

  9:       s_.insert (begin, end);   //  --------- (1)


 10:       addAll_impl (begin, end); // Note virtual call.


 11:     }

 12:   private
:

 13:     virtual
 void
 add_impl (int
 i) = 0;

 14:     virtual
 void
 addAll_impl (int
 * begin, int
 * end) = 0;

 15: };

 16: class
 CountingSet : public
 Set {

 17:   private
:

 18:     int
 count_;

 19:     virtual
 void
 add_impl (int
 i) {

 20:       count_++;

 21:     }

 22:     virtual
 void
 addAll_impl (int
 * begin, int
 * end) {

 23:       count_ += std::distance(begin,end);

 24:     }

 25: };

如果此时我们在父类中修改了addAll函数，改为将从begin到end的数字都调用一遍add函数，那么，子类的功能就紊乱了——子类计数就会 多记录一倍（因为在子类中，add_impl每次都会计数一个，并且addAll_impl也会整体计数一次）。所以，为了防止出现FBC，一般一个公有 非虚函数调用一个私有虚函数。

其次是性能上的考虑，毕竟多了一层函数调用。对此，参考文献2指出：“a word about efficiency: No, none is lost in practice because if the public function is a one-line passthrough declared inline, all compilers I know of will optimize it away entirely, leaving no overhead. (Indeed, some compilers will always make such a function inline and eliminate it, whether you personally really wanted it to or not, but that’s another story.)”

3.总结

将NVI机制放在脑子中吧，如果你还是不明白，一个故事化的讲述 或许更加合适你。

1. 《Effective C++》Item 35 Consider Alternatives To Virtual Functions

2.http://www.gotw.ca/publications/mill18.htm

3.http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.3

4.http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4

5.http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-Virtual_Interface