範型程式設計雜談

萬個函式千個類發表於2013-02-28
程式設計
談範型(GP)之前, 先談一下物件導向(OO), OO強調世界是由物件組成的，物件是由方法和屬性組成的(個人感覺還應該加上事件)，而物件之間又有繼承(is-a)和組合等 關係。OO很符合我們認識世界的直覺，它以封裝，繼承和多型為特性，我們在現實工作中又總結出來了OO的5大設計原則和23種設計模式。總之，OO基本上已經可以很好的解決我們現實生活中的所有問題。

那麼既然OO已經可以很好的解決我們的問題了，為什麼還要有GP? 

我們先來看一下OO的缺點：
OO的多型是通過繼承自同一介面來實現的， 修改介面會導致所有派生類的修改，耦合比較緊密。
OO的多型是執行時的， 效能比較低。
OO的多型通過抽象介面實現，使用不安全，在不支援反射的語言(比如C++)中會喪失型別檢測。 

用OO設計時，你只能通過抽象介面來處理不同的事物。比如你要讓Cat和Dog同時跑動，你可能會抽象出一個IAnimal介面，內部有一個Run的方法，然後讓Cat和Dog分別繼承。但是如果你想讓貓(Cat)和玩具貓(ToyCat)支援跑動，這時你抽象出IAnimal就不合適了， 你可能會抽象出ICatProperty。可以看到OO的這種繼承體系非常笨重，到後面可能會導致非常深的繼承層次(比如MFC)，程式碼擴充套件和維護都很艱難。

上面OO的這些缺點在GP沒有被發現之前都不是缺點，因為我們沒有更好的解決方案，但是人們逐漸發現了GP，GP最初是在使用容器(Container)時被發現的，container<T>可以放任意型別的元素，根據元素型別，我們可以可以生成任意型別的container. 這些技術後來發展成範型程式設計和模板超程式設計。

那麼什麼是GP？
我的理解是 GP是基於concept的程式設計，我們通過concept來定義物件之間的關係。

什麼是concept？
按我的理解，concept就是我們自己定義的概念和規則。

比如說任何物件，只要可賦值，他就符合Assignable的concept:
class A {};
class B {};

void test()
{
   A a1; A a2; a1 = a2;
   B b1; B b2; b1 = b2;
}
上面的A和B就都符合Assignable的concept.

又比如任何物件，只要可比較， 他就符合Comparable的concept:
class C
{
   public:
       bool operator < (const C& c);
       bool operator > (const C& c);
       bool operator == (const C& c);
       bool operator != (const C& c);
       bool operator <= (const C& c);
       bool operator >= (const C& c);
};
上面的物件C，他就符合他就符合Comparable的concept。

再看一個例子:
class Dog 
{
public: 
   void run();
};

class Cat
{
public: 
   void run();
};

template<typename T>
void run(T& t)
{
    t.run();
}
上面的Cat和Dog就都符合擁有成員函式Run這個concept.

GP的concept可以是任何我們能想到的規則，比如包含某個成員變數，或是定義某個型別， 比如下面程式碼:
class myTraits
{
public:
   typedef int type;
   type value;
};

template<typename T>
typename T::type GetValue(T& t)
{
   return t.value;
}

甚至GP的concept可以是指明基類和派生類, 比如下面程式碼：
template<typename TDrived, typename TBase>
class CMyImpl: public TBase
{
public:
     void work()
   { 
      TDrived* p = static_cast<TDrived*>(this);
      p->Hello();
     }
};

class CMyBase {};
class CMyClass: public CMyImpl<CMyClass, CMyBase>
{
public:
     void Hello() {}
};
ATL中大量應用這種concept來實現程式碼重用和模擬虛擬函式。

這些concept在不同語言中定義不一樣，在一些語言中(比如C#)我們可以通過定義來進行顯式約束，表明我們某個concept要滿足哪些條件；在有些語言中(比如C++)則沒有這顯式約束定義，我們只能通過我們程式設計時自己的邏輯來保證，當然如果某個方法要求他的物件滿足某個concept而你的物件沒有滿足 ，編譯器也是不會讓你通過的。

另外GP的concept之間本身也有某種關係， 某個concept可能繼承與另外一個concept，或者說某個concept是另外一個concept的強化，也就是滿足某個concept的物件肯定也同時滿足另外一個concept. 比如concept  A包含Run方法， concept B包含Run和Eat方法，則concept B是concept A的強化，滿足concept B的物件肯定同時滿足concept A。

我們可以看到GP的這種基於concept的設計方式，大大降低了物件之間的耦合性，我們不再要求象OO那樣抽象出共同的介面來讓大家繼承；任何兩個看似沒有關係的物件， 只要他們滿足某個concept的約束，他們就能當作模板引數傳給GP程式碼(模板類或是模板函式)。另外，我們可以看到GP的這些型別檢測是在編譯時就完成的，他的多型是在編譯時就確定的靜多型， 效率大大高於OO的動多型。
 
有些人說GP的抽象能力高於OO，這個觀點我並不認同，我感覺只是他們的抽象方式不一樣，OO是基於介面， 而GP是基於concept。OO的基於介面的抽象，在原始碼和最終執行時都能體現，原始碼中是介面，執行時是虛表，所以他們是一致的， 符合普通人的思維習慣。GP基於concept的抽象， 主要體現在原始碼中 ，只是你用來告訴編譯器你的思維方式， 在執行時他可能是一個完全不同的世界，所以比較難理解。

如果說OO的設計是抽象出介面， GP的設計就是抽象出concept, 滿足某個concept的class是一個template class（如template<typename T> class vector）, 而template class的又可以例項化成某個特定的class(如vector<int>)。 所以GP可以大大減少我們原始碼的數量，但是他本身不能減小我們最終編譯的可執行檔案的大小，相反如果模板類過大，反而會造成程式碼膨脹，而OO的繼承則沒有這個問題（可參考C++模板會使程式碼膨脹嗎）。

對於在實際開發中主要用OO還是用GP的問題， 可能應人和公司而異, 最好的方式當然是OO和GP的靈活結合。有人覺得GP的程式碼不好理解，那是因為你沒有理解他的concept，比如看了《範型程式設計與STL》，你就會發現自己也可以擴充套件STL了。當然，因為C++對concept沒有約束定義機制， 而concept這個東西註釋又不好描述，所以大部分時候我們只能通過原始碼來推理，這在一定程度上也造成了GP程式碼難讀懂這種說法的流行。

相關文章