【C++程式設計技巧】NVI（Non-Virtual Interface ）

在C++的程式設計中有一些設計開發的典型技巧需要整理讨論，在此抛磚引玉，為自己做積累，請高人也多多指教。

1.簡介

在标準C++庫中我們可以看到這樣的一個現象：

6個公有虛函數，并且都是std::exception::what()和其重載。

142個非公有虛函數。

這樣設計的目的何在呢，為什麼“多此一舉”的把虛函數設定為非公有呢？

這就是NVI機制要求的：将虛函數聲明為非公有，而将公有函數都聲明為非虛——虛拟和公有選其一。

2.機制分析

程式員常常将基類中的虛函數公有化，來提供一個接口的定義（virtual的功勞）同時提供其實作（具體的一個實作）。

函數Foo定義了接口的形式，而DoFooX()函數則實作了對Foo函數的行為定制，實作了接口定義和實作的分離，我們舉一個例子來說明好處：如果我們希望在Foo中做一下CS（Critical Section）的加鎖解鎖控制：

若我們完成這樣的接口與實作分離，那麼我們的實作是在基類的接口處添加所需流程即可，子類不需要修改：

若不實作接口與實作分離，則從基類到子類都需要修改：

注意，當且僅當子類需要調用基類的虛函數時才将虛函數設定為protected（否則沒有權限），并且NVI機制不适用于析構函數，對于析構函數，如果設為公有則應該設定為虛拟（在允許多态删除的基類中），否則設定為私有或者protected的非虛拟形式（不含多态删除的基類中）。

帶來的風險：

首先是FBC問題（Fragile Base Class ），下邊是一個例子：

如果此時我們在父類中修改了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.總結

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

本文轉自gnuhpc部落格園部落格，原文連結：http://www.cnblogs.com/gnuhpc/archive/2012/01/17/2324836.html，如需轉載請自行聯系原作者