前幾天跟同事brainstorm，討論一個關於純虛類的使用問題，挺有意思。回來心中久久不能平靜，寫出來一吐為快。

不論在C++中還是C#中，純虛類都是不能例項化的，這是因為純虛類其實是一個對業務型別的一種高度抽象，本質上是不存在這種東西的，所以也就不能例項化它。對於C++中只要類中含有一個純虛擬函式就是純虛類，而C#中是abstract修飾的類就是純虛類，即使類中沒有虛方法也可以是純虛類，在這裡我覺得C#的純虛類沒有C++的嚴謹，如果純虛類中沒有純虛方法的話，那有何意義。

明白了純虛類的原理，那純虛類應該肯定需要被別的類繼承的，因為如果不繼承的話，它自己本身也不能例項化，就沒有存在的意義了，所以它肯定是需要被繼承的。那它需不需要含有一個或者多個純虛方法呢？答案是肯定的，因為既然純虛類是需要被繼承的，那沒有純虛方法又有何意義。沒有純虛方法它就應該是可以例項化的，那就沒有必要將其設定為純虛類的，這也是我吐槽C#的abstract的一個原因。

有了純虛類一定要有純虛方法的這個基礎，那就可以想象純虛類的業務場景應該是下面這個樣子的

    abstract class Goods
    {
        public int GetPrice()
        {
            int price = 0;
            //do some standard things
            price = this.CaculatePrice();
            //do some other steps
            return price;
        }


        protected abstract int CaculatePrice();
    }

我們有一類商品，它們都有一些統一的步驟需要做，先預處理，然後計算價格，這個計算價格是每種商品不一樣的，最後還要統一再處理下，對一個售貨員來說它其實並不關心這是什麼商品有什麼特性，她只關心這個商品的價格，如果購物車中有多個商品，計算出所有商品的總價格。所以一般會構建一個商品，它沒有任何意義，只是將所有商品標準化東西統一起來，將不同的東西抽象為純虛方法，這樣不同的商品就可以只關心它是如何計算價格的，其它不同的部分交給虛基類來處理。這個是比較經典的業務場景，這裡虛基類中可能會有多個public的方法，這些方法可以呼叫純虛方法也是可以的。總之到最後Goods的使用者是直接呼叫Goods索引，而不是操作具體的商品類。這種情況一般純虛類中的純虛方法一般都是private或者protected（在C++中純虛擬函式可以是private、protected和public，但是在C#中純虛擬函式只能是protected和public），因為Goods的使用者一般不會直接操作商品內部的CaculatePrice的，這個應該是需要對使用者隱藏的。設成protected是有些時候需要對Goods再進行抽象，這類商品有它特定的使用者，這個時候它又需要呼叫Goods的方法，這種情況就開發成為protected，比如有一類商品，它們需要提供另外一種方法，計算另外一種型別的價格，但是這種計算方法又是依賴商品的CaculatePrice的結果，繼承類需要再寫一種方法呼叫基類的CaculatePrice的方法，如果是private，繼承類就沒有辦法訪問，此時就需要將其修改成為protected。

看樣子純虛類中的純虛方法是不能為public的，一般是private或者protected的，那是否可以是public呢？答案是可以的。針對上面的例子，假設每種商品沒有統一的步驟，計算方法各不一樣，沒有統一的步驟，那這個時候就需要將GetPrice改成純虛擬函式，但是這裡需要考慮的另外一個問題就是當一個純虛類中有一個public的純虛方法，要考慮這個純虛方法是否是一種interface（這個是C#才有C++中沒有的，這個是一個亮點，將is a和支援的方法隔離開來，因為is a的關係太強了），在這個例子我覺得還是純虛類比較合適，interface不大合適。interface更多的像是一種技能，現實生活中不好想象這樣的例子，在基礎類庫中的IEnumerator這個介面，這個是linq實現的基礎，它就是一個典型的介面而不應該實現為純虛類，list，array和dict它們沒有公共關係，不好抽象出來一個基類來實現is a的關係，但是都需要支援遍歷資料結構中所有元素的方法，所以都實現IEnumerator的介面，所以interface更像一種技能。

在實際開發過程中需求往往是經常漸進，一開始我們並不知道要設計一個純虛類，更多的情況是一開始只有一種商品，設計了Goods，然後有另外一種商品，它們有很大的共性，於是將共性提出來，讓第二個商品繼承第一個商品，其實此時就應該考慮純虛類的，如果未來看得出來有更多同類的商品出現的話，應該重構一個純虛基類出來，但是暫時沒有讓商品2繼承商品1沒問題，因為我覺得增加一個純虛基類出來，而且未來還不知道能不能用上，沒有必要，因為增加純虛基類意味著強型別，將來很難再refactor，第二類太多對程式碼的維護成本也是很高的，基於done is enough的原則，上面直接將商品2繼承商品1沒有問題，即使看上去兩個不應該有繼承關係，所以此時為了更好的解決這個問題，可以考慮將商品1改個名字，讓它們的繼承關係合法化。當商品越來越多的時候大多時候是不會重構出純虛基類的，因為隨著程式碼的不斷增加，維護的成本會指數級增加，而且是修改一個基類，impact會比較大，一般也不會refactor一個純虛基類。除非整個程式碼需要重構，可以考慮這麼做，如果沒有的話，這個程式碼結構不應該進行重構。所以純虛基類一般都是程式碼整體重構的產物，當然如果在需求提出的時候就已經明確那是更好的。

在實際程式碼中我們會經常遇到一個虛方法是一個空函式的，那什麼情況下會將一個虛方法設定為一個空函式呢？

空函式存在的價值是它是有意義的才可以，比如針對上面Goods類，假設它不是純虛類，只是一個基類，如果有種商品就是沒有價格，比如贈品，CalculatePrice直接返回0，沒有任何計算，它的子類商品都有自己的計算價格方法，可以重寫這個方法。所以說針對空函式的話，如果有意義才可以，一般不需要將其設成空函式，沒有意義就可以直接將其改成純虛方法。

總之：

純虛類中是一定要有純虛擬函式的，如果是私有純虛方法那這個方法肯定是被純虛類中其它public呼叫的，如果純虛方法是public的時候是語義上更是is a的關係決定的，但是這個時候需要看看這個方法是否也算是has的方法，如果更多的是has的方法，需要考慮將這個方法改成interface，這個只有c#中才有這種功能，c++中是沒有的，只是一個純虛介面類而已。