談泛型(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:
又比如任何對象，只要可比較， 他就符合Comparable的concept:
再看一個例子:
GP的concept可以是任何我們能想到的規則，比如包含某個成員變量，或是定義某個類型， 比如下面代碼:
甚至GP的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的抽象能力高于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代碼難讀懂這種說法的流行。
不知道大家在實際開發中GP用的多不多?
那么既然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.class B {};
void test()
{
A a1; A a2; a1 = a2;
B b1; B b2; b1 = b2;
}
又比如任何對象，只要可比較， 他就符合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。{
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);
};
再看一個例子:
class Dog
{
public:
void run();
};
class Cat
{
public:
void run();
};
template<typename T>
void run(T& t)
{
t.run();
}
上面的Cat和Dog就都符合擁有成員函數Run這個concept.{
public:
void run();
};
class Cat
{
public:
void run();
};
template<typename T>
void run(T& t)
{
t.run();
}
GP的concept可以是任何我們能想到的規則，比如包含某個成員變量，或是定義某個類型， 比如下面代碼:
class myTraits
{
public:
typedef int type;
type value;
};
template<typename T>
typename T::type GetValue(T& t)
{
return t.value;
}
{
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來實現代碼重用和模擬虛函數。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() {}
};
這些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代碼難讀懂這種說法的流行。
不知道大家在實際開發中GP用的多不多?
浙公網安備 33010602011771號