在C++的程序設計中有一些設計開發的典型機制需要整理討論，在此拋磚引玉，為自己做積累，請高人也多多指教。
1.簡介
在標准C++庫中我們可以看到這樣的一個現象：
6個公有虛函數，並且都是std::exception::what()和其重載。
142個非公有虛函數。
這樣設計的目的何在呢，為什麼“多此一舉”的把虛函數設置為非公有呢？
這就是NVI機制要求的：將虛函數聲明為非公有，而將公有函數都聲明為非虛——虛擬和公有選其一。
2.機制分析
程序員常常將基類中的虛函數公有化，來提供一個接口的定義（virtual的功勞）同時提供其實現（具體的一個實現）。
1: class Base{
2: public:
3: virtual void Foo(int){
4: cout<< "Bases 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 << "Bases DoFoo1" <<endl;
10: }
11: virtual void DoFoo2(){
12: cout << "Bases DoFoo2" <<endl;
13: }
14: };
15:
16: class Derived: public Base{
17: private:
18: virtual void DoFoo1(){
19: cout << "Deriveds 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 << "Bases DoFoo1" <<endl;
12: }
13: virtual void DoFoo2(){
14: cout << "Bases DoFoo2" <<endl;
15: }
16:
17: };
18:
19: class Derived: public Base{
20: private:
21: virtual void DoFoo1(){
22: cout << "Deriveds DoFoo1" << endl;
23: };
24: };若不實現接口與實現分離，則從基類到子類都需要修改：
1: class Base{
2: public:
3: virtual void Foo(){
4: cout << "Locking" << endl;
5: cout << "Bases 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 << "Deriveds 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
